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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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1 Scope 

The present document specifies the UTRAN architecture for 3G Home NodeB (HNB). 

It covers specification of the functions for UEs not supporting Closed Subscriber Groups (CSG) and UEs supporting 
CSGs. It also covers HNB specific requirements for O&M. 

2 References 

The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

For a specific reference, subsequent revisions do not apply. 

For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[I] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". 
[2] 3GPP TS 25.468: "UTRAN luh Interface RUA signalling". 

[3] 3GPP TS 25.469: "UTRAN luh Interface HNBAP signalling ". 

[4] 3GPP TS 25 .40 1 : "UTRAN overall description" . 

[5] 3GPP TS 25.410: "UTRAN lu Interface: general aspects and principles". 

[6] IETF RFC 4960 (September 2007): "Stream Control Transmission Protocol". 

[7] Broadband Forum TR-069 Amendment 2, CPE WAN Management Protocol, Broadband Forum 

Technical Report, 2007. 

[8] 3GPP TS 25.444: "luh data transport and transport signalling". 

[9] 3GPP TS 25.413: "UTRAN lu Interface RANAP Signalling". 

[10] 3GPP TS 23.060: "General Packet Radio Service (GPRS); Service Description; Stage 2". 

[II] 3GPP TS 22.220: "Service requirements for Home NodeBs and Home eNodeBs". 
[12] 3GPP TS 25.419: "UTRAN lu Interface: Service Area Broadcast Protocol SABP". 
[13] Void 

[14] Void 

[15] Void 

[16] 3GPP TS 33.320: "Security of Home Node B (HNB) / Home evolved Node B (HeNB)". 

[17] 3GPP TS 25.415: "UTRAN lu Interface user plane protocols". 

[18] 3GPP TS 25.423: "UTRAN lur interface Radio Network Subsystem Application Part (RNSAP) 

SignalHng". 

[ 1 9] 3GPP TS 25 .47 1 : "UTRAN lurh Interface RNSAP User Adaption (RN A) signalling" . 

[20] Void 
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[21] 3GPP TS 25.425: "UTRAN lur interface user plane protocols for Common Transport Channel data 

streams". 

[22] 3GPP TS 25.427: "UTRAN lub/Iur interface user plane protocol for DCH data streams". 

[23] 3GPP TS 25.104: "Base Station (BS) radio transmission and reception (FDD)". 

[24] 3GPP TS 32.642: "Telecommunication management; Configuration Management (CM); UTRAN 

network resources Integration Reference Point (IRP); Network Resource Model (NRM)". 

[25] 3GPP TS 25.331: "Radio Resource Control (RRC); Protocol specification". 

[26] 3GPP TS 24.008: "Mobile radio interface Layer 3 specification; Core network protocols; Stage 3". 

[27] 3GPP TS 32.652: "Telecommunication management; Configuration Management (CM); GERAN 

network resources Integration Reference Point (IRP); Network Resource Model (NRM)". 

[28] 3GPP TS 25.101: "User Equipment (UE) radio transmission and reception (FDD)". 

[29] 3GPP TS 25.304: "User Equipment (UE) procedures in idle mode and procedures for cell 

reselection in connected mode". 

[30] Void 

[31] 3GPP TS 25.420: "UTRAN lur interface general aspects and principles". 

[32] ITU-T Recommendation Q.71 1 (1996-07): "Functional description of the signalling connection 

control part". 

[33] ITU-T Recommendation Q.712 (1996-07): "Definition and function of signalling connection 

control part messages". 

[34] ITU-T Recommendation Q.713 (1996-07): "Signalling connection control part formats and codes". 

[35] ITU-T Recommendation Q.714 (1996-07): "Signalling connection control part procedures". 

[36] 3GPP TS 23.139: "3GPP system - fixed broadband access network interworking". 

3 Definitions, symbols and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in TR 21.905 [1] and the following apply. A 
term defined in the present document takes precedence over the definition of the same term, if any, in TR 2 1 .905 [ 1 ] . 

HNB, Home NodeB, 3G Home NodeB: as defined in TS 22.220 [11]. These terms, their derivations and abbreviations 
are used synonymously throughout this document. 

CSG HNB: A HNB that serves a CSG Cell, broadcasting a CSG Indicator and a specific CSG identity. 

Non CSG HNB: A HNB that serves a cell which neither broadcasts a CSG Indicator nor a CSG Identity. 

Hybrid HNB: A HNB that serves a hybrid cell not broadcasting a CSG Indicator but broadcasting a CSG identity. 

Membership Verification: The process that checks whether a UE is a member or non-member of a hybrid cell. 

Access Control: The process that checks whether a UE is allowed to access and to be granted services in a closed cell. 

CSG ID Validation: The process that checks whether the CSG ID sent via relocation messages is the same as the one 
supported by the target RAN. 

RNSAP Relocation: denotes enhanced mobility for inter-HNB Relocation via RNS AP. In this version of the 
specification, RNSAP Relocation is only defined for intra-PLMN intra-HNB-GW intra-CSG scenarios. 
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3.2 



Abbreviations 



For the purposes of the present document, the abbreviations given in TR 21.905 [1] and the following apply. An 
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 
TR 21.905 [1]. 

CS Circuit Switched 

CSG Closed Subscriber Group 

DSL Digital Subscriber Line 

DSL-GW DSL Gateway 

GNSS Global Navigation Satellite System 

GPS Global Positioning System 

HMS Home NodeB Management System 

HNB 3G Home NodeB 

HNB-GW 3G HNB Gateway 

HW Hard Ware 

IP Internet Protocol 

L-GW Local GateWay 

LAC Local Area Code 

LIPA Local IP Access 

PCRF Policy and Charging Rules Function 

RAC Routing Area Code 

RGW Residential GateWay 

SAC Service Area Code 

SCCP Signalling Connection Control Part 

SeGW Security GateWay 

SGW Serving GateWay 

SW Software 



£75/ 



3GPP TS 25.467 version 11.2.0 Release 11 



10 



ETSI TS 125 467 V1 1.2.0 (2013-04) 



Overall architecture 



4.1 



General 



The overall UMTS architecture and UTRAN architectures are described in TS 25.401 [4] and TS 25.410 [5]. For clarity 
and ease of understanding, at appropriate places references to TR-069 [7] and associated methods are described briefly 
although they are beyond the scope of this specification. 

The reference model shown in Figure 4.1-1 below contains the network elements that make up the HNB access 
network. There is a one-to-many relationship between a HNB-GW and the HNB(s) it serves. 

A 
— Gi 



Uu 



T 

L-GW 



HNB 



Gn/S5 



luh 



I 



Uu 



lurh 



luh 



HNB 

L-GW 



Gn/S5 



Security 
Gateway 



HNBGW 



S15 



HMS 



Figure 4.1-1. HNB access network reference model. 

The HNB-GW appears to the CN as an RNC and serves as a concentrator of HNB connections. The lu interface 
between the CN and the HNB-GW serves the same purpose as the interface between the CN and a RNC. The HNB GW 
is uniquely identified towards the CN on a particular lu interface by the RNC ID. One HNB serves only one cell. 

The HNB-GW appears to other RNCs as an RNC and serves as a concentrator of HNB connections. The HNB GW is 
uniquely identified towards the RNC on a particular lur interface by the RNC ID. 

The Local Gateway (L-GW) may be present only when the HNB operates in LIPA mode. When present, it is co-located 
with the HNB, in which case the HNB has a Gn/S5 interface towards the SGSN/SGW which does not use the HNB- 
GW, and a Gi interface towards the residential/IP network. 

If the L-GW is present within the HNB, the HNB shall use for Gn/S5 connectivity the same secure interface established 
by the HNB for luh signalling as specified in TS 33.320 [16]. 

If the HNB-GW is supporting Fixed Broadband Access network interworking function, the HNB-GW uses a S15 
interface towards PCRF for CS sessions as specified in TS 23.139 [36]. 

The HNB may be assigned the same inner IP address for the Gn/S5 interfaces as for the luh interface, or a different IP 
address. 

NOTE: If the HNB uses the same IP address for Gn/S5 and the luh interface, they should be assigned distinct 
ranges of TEIDs in order to be able to discriminate downlink GTP-U packets. 

NOTE: The Security gateway is a logically separated entity and may be implemented either as a separate physical 
element or integrated into, for example, a HNB-GW. 
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The HNB access network includes the functional entities as shown in Figure 4.1-1 and detailed below. 

The HNB access network supports lurh connectivity between HNBs and connectivity between HNBs and RNCs via the 
HNB-GW. 

This version of specification supports three different lurh connectivity options: 

Option 1: Direct lurh interface connectivity between the two involved HNBs. 
In this case the HNB-GW is not involved at all in lurh RNL signalling. 

Option 2: lurh interface connectivity between HNBs with the HNB-GW serving as an lurh proxy. 

In this case the HNB-GW, acting as an lurh-proxy, appears to a HNB as the peer HNB. 

For this connectivity option the role of the HNB-GW is transparent with regard to RNSAP signalling. Conveying 

respective signalling messages via the HNB-GW is performed by routing based on information provided by the 

RNSAP User Adaptation (RNA) layer, see TS 25.471 [19]. 

Option 3: lurh interface connectivity between HNBs and the HNB-GW utilised for transporting RNL signalling 
between those HNBs and RNCs via the HNB-GW. 

NOTE: If Option 2 and Option 3 coexist, they share the same SCTP association. 

lurh connectivity between one pair of HNBs shall either support direct lurh connectivity or lurh connectivity via the 
HNB-GW, not both at the same time. 

With respect to HNB-HNB mobility, there is no requirement for a HNB to support direct lurh connectivity and lurh 
connectivity via the HNB-GW at the same time in the current release of the specification. 

4.1 .1 HNB Management System (HMS) 

The HMS: 

is based on the TR-069 family of standards [7]. 

facilitates HNB-GW discovery. 

provides configuration data to the HNB. 

performs location verification of HNB and assigns appropriate serving elements (HMS, Security Gateway and 
HNB-GW). 

4.1 .2 Security Gateway (SeGW) 

The SeGW: 

terminates secure tunnelling for TR-069 [7] as well as luh. 
terminates secure tunnelling for lurh and Gn/S5 for certain deployment options, 
authenticates HNBs. 
- provides the HNB with access to the HMS and HNB-GW. 

4.1 .3 HNB Gateway (HNB-GW) 

The HNB Gateway: 

terminates luh from HNB and appears as an RNC to the Core network. 

supports HNB registration and UE registration over luh. 

may terminate TNL for the lurh interface, in case lurh connectivity via the HNB-GW is deployed for at least one 
HNB or connectivity to an RNC via the HNB-GW. 

may support Fixed Broadband Access network interworking via S15 interface towards PCRF for CS sessions as 
specified in TS23. 139 [36]. 
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4.1.4 HNB 

The HNB: 

offers the Uu Interface to the UE. 

provides RAN connectivity using the luh and lurh interfaces. 

acts as RNS (details are captured in Table 4.2-1). 

supports HNB registration and UE registration over luh. 

In case of LIP A support, it supports the following additional functions: 

transfer of the Gn/S5 IP address of the HNB over luh. 

support of basic GGSN/P-GW functions in the collocated L-GW function by support of the Gi/SGi interface 
corresponding to LIPA. 

Support of use of the Correlation ID for correlation purposes between the collocated L-GW function and the 
HNB. 

In case of Fixed Broadband Access network interworking support, it supports transferring of Tunnel 
Information over lu/Iuh as specified in TS 23.139 [36]. 

4.1.5 L-GW 

The L-GW function within the HNB provides: 

- in Idle mode, support for sending the first packet to the SGSN/SGW and, buffering of subsequent downhnk 
packets. 

support of internal direct user plane path towards the corresponding HNB user plane functions. 

deactivation of the Gn/S5 interface connection. 

The mobility of the LIPA PDN connection is not supported in this Release of the specification. The LIPA connection is 
always released with handover as described in TS 23.060 [10]. 



4.2 Functional split 



The UTRAN functions in the HNB are supported by RANAP, whereas the HNB specific functions are supported by the 
Home NodeB Application Protocol (HNBAP) between the HNB and the HNB-GW. The HNB-GW provides a 
concentration function for the control plane and may provide a concentration function for the user plane. 

This sub-clause defines the functional split between the core network and the UMTS radio access network. The 
functional split is shown in Table 4.2-1 and 4.2-2. 
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Table 4.2-1 . Functional split for UTRAN function in the HNB access. 



Function 


HNB 


HNB-GW 


CN 


RAB management functions: 








RAB establishment, modification and release 


X 


w Note 1 


X 


RAB characteristics mapping !„ transmission bearers 


X 


X 




RAB characteristics mapping Uu bearers 


X 






RAB queuing, pre-emption and priority 


X 




X 


Radio Resource Management functions: 








Radio Resource admission control 


X 






Broadcast Information 


X 


y Note 2 


X 


lu linl< Management functions: 








lu signalling link management 


X 


X 


X 


ATM VC management 




X 


X 


AAL2 establish and release 




X 


X 


AAL5 management 




X 


X 


GTP-U Tunnels management 


X 


X 


X 


TCP Management 




X 


X 


Buffer Management 


X 


X 




lu U-plane (RNL) Management: 








lu U-plane frame protocol management 






X 


lu U-plane frame protocol initialization 


X 






Mobility management functions: 








Location information reporting 


X 




X 


Handover and Relocation 
Inter RNC hard HO, lur not used or not available 
Serving RNS Relocation (intra/inter MSC) 
Inter system hard HO (UMTS-GSM) 








X 


X 


X 


X 


X 


X 


X 


X 


X 


Inter system Change (UMTS-GSM) 


X 




X 


Paging Triggering 


X 




X 


Paging Optimization 




X 




GERAN System Information Retrieval 


X 




X 


Security Functions: 








Data confidentiality 
Radio interface ciphering 
Ciphering key management 
User identity confidentiality 








X 










X 


X 




X 


Data integrity 
Integrity checking 
Integrity key management 








X 










X 


Service and Network Access functions: 








CN Signalling data 


X 




X 


Data Volume Reporting 


X 






UE Tracing 


X 




X 


Location reporting 


X 




X 


lu Co-ordination functions: 








Paging co-ordination 


X 




X 


NAS Node Selection Function 




X 




MOCN Rerouting Function 




X 


X 


Note 1 : This function could be needed for TNL address translation in the HNB-GW when there is no user 
plane direct transport connection between HNB and CN 

Note 2: HNB-GW is able to perform the filtering of SABP messages i.e. determines from the SAI list to which 
HNB the SABP message needs to be sent and then distributes the SABP messages to the 
appropriate HNBs. This is an optional function in HNB-GW. 
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Table 4.2-2. Functional split for HNB function in the HNB access. 



Function 


HNB 


HNB-GW 


CN 


HNB Registration ™'^ ' 








HNB Registration Function 


X 


X 




HNB-GW Discovery Function 


X 






HNB de-registration Function 


X 


X 












UE Registration for HNB "°'^ ' 








UE Registration Function for HNB 


X 


X 




UE de-registration Function for HNB 


X 


X 












luh user-plane Management functions 








luh User plane transport bearer handling 


X 


X 




Functions for multiplexing CS user plane on the Uplink 


X 


X 












Traffic Offload Functions 








LIRA 


X 




X 










Enhanced Interference Management 








Mitigation of Interference from HNB to l\/lacro 


X 














UE Access Control / Membership Verification 








IDLE mode 


wNote2 


X 


X 


Connected mode (inbound relocation to HNB cells) 




X 


X 


CSG ID validation 


X 


X 




CSG Subscription Expiry 


X 


X 


X 










lurh Connectivity Functions 








lurh Establishment 


X 


^Note ci 




Exchange of lurh Connectivity data for neighbour HNBs 


X 


X 












Fixed Broadband Access network Interworking 








CS sessions 


X 


X 


X 


PS sessions 


X 




X 


Note 1 : Protocol support for this group of functions is provided by the HNB Application 

Protocol. 
Note 2: Access control or membership verification at the HNB are optional. 
Note 3: If the HNB-GW is involved in lurh Establishment for lurh connectivity option 2, it acts 

only as pure relay for this signalling. 



UTRAN functions for HNB access 



5.1 UE Registration 



5.1.1 



General 



The UE Registration Function for HNB provides means for the HNB to convey UE identification data to the HNB-GW 
in order to perform access control or membership verification for the UE in the HNB-GW. The UE Registration also 
informs the HNB-GW of the specific HNB where the UE is located. 

The following sections illustrate the case when the HNB registers a specific UE with the HNB-GW. The registration is 
triggered when the UE attempts to access the HNB via an initial NAS message (e.g.., Location Updating Request) and 
there is no context in the HNB allocated for that UE. 
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5.1 .2 UE Registration: case of non CSG UEs or non CSG HNBs 





HNBGW 



1. RRC Connection Est. UE identity, UE Rel, UE Cap, 



3. Optional Identity request 



2. RRC Initial Direct Transfer 



(e.g. LU Request,. 



Check Release, 
UE Capabilities 



4. Optional Access Control/ 

Membership Verification 

(IMSI, HNB) 



5. UE Registration Req (UE idfintity, UE Rel, UE Cap 




6. Access Control/ 

Membership Verification 

(IMSI, HNB) 



7. UE Registration Accept (Cor text-id,..) 



8. Connect (Initial UE Messag(j, „ ) 



9.'SCCP CR (Initial UE Message, .. ) 



10. SCCPCC 



1 1 . Continue with NAS procedure 



Figure 5.1.2-1. UE Registration for non CSG UEs or non CSG HNBs. 

1. Upon camping on the HNB, the UE initiates an initial NAS procedure (e.g. LU Procedure) by establishing an 
RRC connection with the HNB. UE identity, UE capabilities and Establishment Cause, are reported to the HNB 
as part of the RRC Connection establishment procedure. 

2. The UE then transmits a RRC Initial Direct Transfer message carrying the initial NAS message (e.g. Location 
Updating Request message) with some form of UE identity. 

3. The HNB checks the UE capabilities provided in step 1, and if these indicate that CSG is not supported, or the 
HNB itself does not support CSG, and if the identity of the UE (provided during RRC Connection 
Establishment) is unknown at the HNB being accessed, i.e. no Context id exists for the UE, the HNB initiates 
UE registration towards the HNB-GW (step 5-7). Before starting the UE Registration procedure, the HNB 
triggers the Identity request procedure (step 3) asking the UE for its IMSI, unless that identity has been provided 
during the RRC Connection Establishment or optionally if it is an emergency call. If the HNB has a context id 
for the UE, the UE registration procedure is not performed nor is the Identification procedure. 

4. The HNB may optionally perform access control or membership verification based on the provided IMSI and the 
provided Allowed IMSI list. If the UE requests emergency services it shall always be admitted to the cell. 

5. The HNB attempts to register the UE on the HNB-GW by transmitting the UE REGISTER REQUEST. The 
message contains at a minimum: 

UE Identity: a unique identity for the UE provided in step 1 or 3. 

UE Capabilities: derived from that provided in step 1 . 

Registration Cause: the indication about a UE registration for an emergency call. 

NOTE: The UE Identity provided in the HNBAP UE REGISTER REQUEST message is unauthenticated. 
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6. The HNB-GW checks the UE capabihties and the Registration Cause. If the UE capabihties indicate that CSG is 
not supported or if the HNB does not support CSG, the HNB-GW shall perform access control or membership 
verification for the particular UE attempting to utilize the specific HNB. If the UE requests emergency services it 
shall always be admitted to the cell. 

7. If the HNB-GW accepts the UE registration attempt it shall allocate a context-id for the UE and respond with an 
HNBAP UE REGISTER ACCEPT message, including the context-id, to the HNB. For non-CSG UEs, the HNB- 
GW may also include the CSG Membership Status in the HNBAP UE REGISTER ACCEPT message. If the 
HNB-GW chooses not to accept the incoming UE registration request then the HNB-GW shall respond with an 
HNBAP UE REGISTER REJECT message. 

8. The HNB then sends an RUA CONNECT message containing the RANAP Initial UE message. If a L-GW 
function is deployed within the HNB the RANAP Initial UE message includes the corresponding IP address for 
Gn/S5 signalling and user data transport on the Gi interface. 

9. The reception of the RUA CONNECT message at the HNB-GW triggers the setup of an SCCP connection by the 
HNB-GW towards the CN. The HNB-GW then forwards the RANAP Initial UE Message to the CN. 

10. The CN responds with an SCCP Connection Confirm message. 

10a. The HNB-GW shall additionally utilize a CN assisted method if available (e.g. using IMSI provided in the 
COMMON ID message), to alleviate the security risks associated with spoofing of IMSI and can subsequently 
trigger a UE deregistration upon detection of such an event. 

11. The UE continues with the NAS procedure (e.g. Location Updating procedure) towards the CN, via the HNB 
and the HNB-GW. 

5.1 .3 UE Registration: case of CSG UEs and CSG or Hybrid HNBs 

This call flow assumes that the Core Network is able to perform access control on the basis of Closed Subscriber 
Groups. 



UE 



HNB 



HNBGW 



1. RRC Connection Est. (TMSI or IMSI, UE Rel, UE Cap, ..) 



2. RRC Initial Direct Transfer (e.g. LU Request,...) 



3. Check Release, 
UE Capabilities 



4. UE Registration (TMSI or II /ISI, Rel, UE Cap,.. ) 



CN 



5. UE Registration 



6. UE Registration Accept (Context-id,..) 



7. Connect (Initial UE Message;,.. ) 



10. Optional MM 



8. SCCP CR (Initial UE Message,.. ) 



9. SCCP CC 



1 . Access Control or 
Membership 



12. Continue with NAS procedure 



Figure 5.1.3-1. UE Registration for CSG UEs and CSG or Hybrid HNBs. 
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1. Upon camping on the HNB, the UE initiates an initial NAS procedure (e.g. LU Procedure) by establishing an 
RRC connection with the HNB. UE identity and UE capabilities are reported to the HNB as part of the RRC 
Connection establishment procedure. 

2. The UE then transmits a RRC Initial Direct Transfer message carrying the initial NAS message (e.g. Location 
Updating Request message) with some form of identity (e.g. IMSI or TMSI...). 

3. The HNB checks the UE capabilities provided in step 1, and if these indicate that CSG is supported and if the 
identity of the UE (provided during RRC Connection Establishment) is unknown at the HNB being accessed, i.e. 
no Context id exist for the UE, the HNB initiates UE registration towards the HNB-GW (steps 4-6). If the HNB 
has a context id for the UE, UE registration procedure is not performed. No Identification procedure is triggered, 
independent of the identity reported by the UE during the RRC Connection Establishment. 

4. The HNB attempts to register the UE on the HNB-GW by transmitting the UE REGISTER REQUEST. The 
message contains: 

UE Identity: a unique identifier for the UE and provided in step 1 . 

UE capabilities: derived from that provided in step 1 . 

Registration Cause: the indication about a UE registration for an emergency call. 

NOTE: The UE Identity provided in the UE REGISTER message is unauthenticated. 

5. The HNB-GW checks UE capabilities and if these indicate that CSG is supported and if the HNB supports CSG, 
the HNB-GW may accept the UE registration and allocate a context-id for the UE. 

6. The HNB-GW responds with a UE REGISTER ACCEPT message back to the HNB including a context-id 
allocated to the UE 

7. The HNB then sends a RUA CONNECT message containing the RANAP Initial UE message. The RANAP 
Initial UE message may contain the Cell Access Mode. If a L-GW function is deployed within the HNB, the 
RANAP Initial UE message includes the corresponding IP address for Gn/S5 interface signalling and user data 
transport on the Gi interface. 

8. The HNB-GW shall verify the validity of the indicated cell access mode and, for CSG cells, the CSG ID in the 
Initial UE message as specified in TS 33.320 [16]. The reception of the RUA CONNECT message at the HNB- 
GW triggers the setup of an SCCP connection by the HNB-GW towards the CN. The HNB-GW then forwards 
the Initial UE Message including the CSG id of the HNB. 

9. The CN responds with an SCCP Connection Confirm message. 

10. The CN may optionally perform Mobility Management procedures, e.g. Authentication procedure. 

1 1 . The CN performs access control (in case of CSG cells) or membership verification (in case of Hybrid cells) of 
theUE. 

12. After being granted access the UE then continues with the NAS procedure (e.g. Location Updating procedure) 
towards the CN, via the HNB and the HNB-GW. During such procedures the CN may send to the HNB the UE 
membership status for the accessed cell in the COMMON ID message. 



5.1 .4 HNB-GW triggered UE Registration 



The following section describes the mechanism, which is used to manage UE registration and associated context IDs for 
the scenarios based on HNB-GW triggered setup of UE-associated Signalling Connection. 

In this mechanism, the RUA Connect message is used for transporting the first RANAP message resulting in network 
triggered setup of UE-associated Signalling Connection (e.g. RANAP Relocation Request). 
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Target 
HNB 



HNB GW 



0. Relocation Trigger 



1 . Determine Target HNB 



2. RUA CONNECT (UE Context Id , CN 

domain, RANAP Relocation Request) 



3a) Implicit UE Registration 

3b) Allocate resources for relocation 



4. RUA DIRECT TRANSFER (UE Context Id, 
CN domain, RANAP Relocation Request Ack) 



Figure 5.1.4-1. HNB-GW Triggered UE Registration. 

The above call flow assumes that the HNB-GW receives a trigger for inbound relocation for a UE (e.g. RANAP 
Relocation Request message from the CN) as shown in step 0. 

1. The HNB-GW receives a RANAP message and determines the target HNB. 

2. The HNB-GW sends the RANAP message encapsulated in the RUA Connect message to the target HNB. The RUA 
Connect Message may contain the CSG Membership Status IE. 

3. The HNB-GW and the target HNB perform an implicit registration (HNB-GW establishes a UE specific Context 
Identifier to be used between the HNB and the HNB-GW, i.e., either re-use the existing Context Identifier if already 
present for the UE or otherwise allocate a new one) for the incoming UE session. The HNB also allocates the 
appropriate resource for handling the request in the RANAP message. 

4. The RANAP reply message from the HNB to the HNB-GW is encapsulated in the RUA Direct Transfer message. 

In the case that the target HNB rejects the inbound relocation, the rejection message (e.g. RANAP Relocation Failure) is 
carried by a RUA Disconnect message, an implicit UE Deregistration takes place, and the resources allocated for 
handing the request are released. 
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5.1 .5 UE Registration: case of Open Access HNBs 



UE 



HNB 



HNBGW 



1. RRC Connection Est. (TMSI or IMSI, UE Rel, UE Cap, ..) 



2. RRC Initial Direct Transfer (e.g. LU Request,...) 



3. Check UE 
Identity 



4. UE Registration (TMSI or II /ISI, Rel, UE Cap,.. ) 



CN 



5. UE Registration 



6. UE Registration Accept (Context-id,..) 



7. Connect (Initial UE Messagfi,.. ) 



10. Optional MM 



8. SCCP CR (Initial UE Message,.. ) 



9. SCCP CC 



11. Continue with NAS procedure 



Figure 5.1.5-1. UE Registration to open access HNBs. 

1. Upon camping on the HNB, the UE initiates an initial NAS procedure (e.g. LU Procedure) by establishing an 
RRC connection with the HNB. UE identity and UE capabilities are reported to the HNB as part of the RRC 
Connection establishment procedure. 

2. The UE then transmits a RRC Initial Direct Transfer message carrying the initial NAS message (e.g. Location 
Updating Request message) with some form of identity (e.g. IMSI or TMSI). 

3. If the identity of the UE (provided during RRC Connection Establishment) is unknown at the HNB being 
accessed, i.e. no Context id exist for the UE, the HNB initiates UE registration towards the HNB-GW (steps 4- 
6). If the HNB has a context id for the UE, UE registration procedure is not performed. No Identification 
procedure is triggered, independent of the identity reported by the UE during the RRC Connection 
Establishment. 

4. The HNB attempts to register the UE on the HNB-GW by transmitting the UE REGISTER REQUEST. The 
message contains: 

UE Identity: a unique identifier for the UE and provided in step 1 . 

UE capabilities: derived from that provided in step 1 . 

Registration Cause: the indication about a UE registration for an emergency call. 

NOTE: The UE Identity provided in the UE REGISTER message is unauthenticated. 

5. The HNB-GW may accept the UE registration and allocate a context-id for the UE. 

6. The HNB-GW responds with a UE REGISTER ACCEPT message back to the HNB including a context-id 
allocated to the UE. 

7. The HNB then sends a RUA CONNECT message containing the RANAP Initial UE message. 
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8. The reception of the RUA CONNECT message at the HNB-GW triggers the setup of an SCCP connection by the 
HNB-GW towards the CN. The HNB-GW then forwards the Initial UE Message to the Core Network. 

9. The CN responds with an SCCP Connection Confirm message. 

10. The CN may optionally perform Mobility Management procedures, e.g. Authentication procedure. 

1 1. After being granted access the UE then continues with the NAS procedure (e.g. Location Updating procedure) 
towards the CN, via the HNB and the HNB-GW. 

5.2 HNB Registration 

5.2.1 General 

The following section illustrates the case when the HNB registers with the HNB-GW. The HNB registration procedure 
serves the following purposes: 

It informs the HNB-GW that a HNB is now available at a particular IP address. 

5.2.2 HNB Registration procedure 



HNB SeGW 



HNB-GW 



1. HNB Initialization 



2. Establisti secure tunnel 



3. Establish Reliable Transport Session for luh signalling 
4. HNB REGISTER REQUEST (Location Information, HNB Identity, HNB Operating Parameters) 



6a. HNB REGISTER ACCEPT (...) 



6b. HNB REGISTER REJECT (Reject Cause) 



6. Establish Reliable Transport Session for iurb signalling 



Figure 5.2.2-1. HNB Registration procedure. 

1. HNB initialization is performed to obtain HNB configuration from the HNB Management System (HMS). 
Similarly, HNB-GW discovery is performed to obtain the initial serving HNB-GW information. 

2. The HNB establishes a secure tunnel to the SeGW of the serving HNB-GW. 

NOTE: This step may be omitted if the secure tunnel happens to be the same tunnel that is already established to 
contact the HMS. 

3. The HNB sets up an SCTP transport session to the registered port on the serving HNB-GW for luh. 

4. The HNB then attempts to register with the serving HNB-GW using an HNB REGISTER REQUEST message. 
The message contains: 

a. HNB Location Information: The HNB provides location information via use of one or more of the 
following mechanisms: 
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i. Detected macro-cell coverage information (e.g. GERAN or UTRAN cell information). 

ii. Geographical co-ordinates (e.g. via use of GPS, etc). 

iii. Internet connectivity information (e.g. IP address), provided, the resulting location information is at least 
as accurate as location determination based on macro-cell coverage information, whether or not there is 
macro cell-coverage available at the location of the HNB (e.g. as determined by point i above). 

b. HNB Identity: the HNB has a globally unique and permanent identity. 

c. HNB Operating Parameters: Such as the selected LAC, RAC, SAC, PLMN Id, Cell Id, etc. 

d. HNB operating mode (optional): HNB CSG-Id or access mode (open, closed or hybrid). 

e. HNB's own IP address for direct lurh connectivity (if lurh connectivity is supported by the HNB). 

5a. The HNB-GW may use the information from the HNB REGISTER REQUEST message to check whether the 
HNB registration can be accepted (e.g. to check whether a particular HNB is allowed to operate in a given 
location, etc). The HNB-GW shall verify the HNB identity, the validity of the indicated cell access mode and, 
for CSG cells, the CSG ID as specified in TS 33.320 [16]. If the HNB-GW accepts the registration attempt it 
shall respond with a HNB REGISTER ACCEPT message. If the HNB-GW has capability to de-multiplex, the 
HNB-GW may include a mux port in the HNB REGISTER ACCEPT message. The HNB shall include the RNC- 
ID provided by the HNB-GW within relevant RANAP messages in order to identify the HNB-GW during 
mobility procedures and within RRC messages, where the RNC-ID has to be contained within the most 
significant bits of the Cell Identification and be part of the U-RNTI. The HNB-GW may provide its IP address in 
order to allow the HNB to either establish lurh-connectivity via the HNB-GW or to establish connectivity to an 
RNC via the HNB-GW. 

5b. Alternatively, the HNB-GW may reject the registration request (e.g. due to network congestion, blacklisted 
HNB, unauthorized HNB location, etc). In this case, the HNB-GW shall respond with an HNB REGISTER 
REJECT indicating the reject cause. 

6. If the HNB-GW had provided in the HNB REGISTER ACCEPT message the HNB-GW"s own IP address for 
lurh connectivity via/to the HNB-GW, the HNB shall, if supported, set up an SCTP transport session to the port 
registered for lurh. 

NOTE: The HNB shall start broadcasting only after successful registration with the HNB-GW. 

5.3 HNB-GW Discovery Function 
5.3.1 General 

The HNB-GW Discovery Function provides the means to determine the address of the Serving HNB-GW for a 
particular HNB. The HNB uses the Serving HNB-GW address to register with the Serving HNB-GW. 

5.4 HNB de-registration Function 
5.4.1 General 

The HNB de-registration Function provides the means to terminate the HNB operation. The HNB de-registration can be 
initiated by either the HNB or the HNB-GW. 

5.5 luh Disconnect 
5.5.1 General 

The following section illustrates the scenario where an UE-associated signalling connection is released across the luh. 
In this scenario the HNB is responsible for initiating the release of the UE-associated signalling connection via the RUA 



£75/ 



3GPP TS 25.467 version 11.2.0 Release 11 



22 



ETSI TS 125 467 V1 1.2.0 (2013-04) 



disconnect message. The HNB-GW is then responsible for co-ordinating the release of the UE-associated luh signalUng 
connection with the corresponding lu connection, which is triggered by the CN. 

5.5.2 luh Disconnect procedure 



UE 



HNB 



HNB-GW 



CN 



1. Establish Connection between UE and Network 



3. RUA Direct Transfer (Context - 

Id, CN Domain Id , RANAP 

lu Release Command ) 



2. SCCP:DT1 (RANAP 
lu Release Command) 



4. Release RRC Connection 



5. RUA Disconnect (Context -ID, 
CN Domain ID , RANAP lu Release 
Complete) 



6. SCCP:DT1 (RANAP 
lu Release Complete) 



7. SCCP: RLSD 



8. SCCP: RLC 



9. (opt) HNBAP UE 
De-register (Context-ID) 



Figure 5.5.2-1 : luh Disconnect procedure. 

1. Establish connection between UE and network. The related procedure is described in subclause 5.1. 

2. CN sends a RANAP Release lu connection command message to the HNB-GW. 

3. HNB-GW forwards this message to the relevant HNB. 

4. HNB triggers the release of the RRC connection to the UE. In this case a single lu connection had been 
established for the UE. 

5. HNB sends a Disconnect message to the HNB-GW to indicate that this is the end of this particular UE- 
associated signalling connection and includes the RANAP Release lu Connection Complete message. 

6. HNB-GW forwards the RANAP message onto the CN. 
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7. CN triggers the release of the associated SCCP connection. 

8. HNB-GW confirms that the SCCP connection is released. 

9. Optionally the HNB can de-register the UE context from the HNB-GW. 

5.6 Paging Optimization Function 
5.6.1 General 

The paging optimization function provides the means to decrease the impact of a paging load over luh (for example, via 
the use of knowledge about the UE Registration or its CSG Id List in the PAGING message). 

5.7 HNB to HNB IVIobility 

5.7.1 General 

The following sub-sections describe the mechanism for handling the intra HNB-GW mobility signalling via lurh. 

5.7.2 Connected mode mobility from one HNB to another HNB (Intra 
PLIVIN, Intra HNB-GW, Intra CSG) 

5.7.2.1 C-Plane Handling 

RNSAP Relocation utilises existing protocol functions specified for Enhanced Relocation between non-CSG cells 
within TS 25.413 [9] and TS 25.423 [18]. 

Additional information from the Source HNB to the Target HNB is provided within the RANAP Enhanced Relocation 
Information and the RANAP Relocation Information procedures as specified in subclause 5.10. 

Figure 5.7.2.1-1 below depicts the case where the UE is involved in the RNSAP Relocation and the HNBs are directly 
lurh-connected. In case of UE not being involved, an lurh signalling connection (i.e. RNA signalling resources) already 
exists between the involved HNBs which can be utilised for RNSAP signalling. In case of lurh-connectivity via the 
HNB-GW, RNA signalling terminates at the HNB-GW, whereas RNSAP signalling is still performed peer-to-peer. 
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Tarqet 
UE Source HNB H^JF 

1. RNA ConnectrRNSAPEn 
Relocation Request (UE Id, ifcANAP 
Relocation Information Reg i est...) 



5. RRC RB 
Reconfiguration 



znnanced 



3. RNA Direct Transfer: RNSAP |nhanced 
Relocation Response 



4. RNA Direct Transfer: RNSAf 
Relocation Commit 



6. RRC RB Rec( nflguratlon Complete 



HNB-GW 



CN 



2a. HNBAP TNL Update Requ( st 
(Accepted RAB List...) 



2b. HNBAP TNL Update Resp< nse 



Detect UE sync 
7. HNBAP Relocation Complete 



Sa.RAB Release Request 



Unaccepted RABs) 



8b. RAB Assignment Procedure to release unaccepted RABs 



9. HNBAP UE De-Reglstratlon 



10. RNA Disconnect: RNSAf 

Enhanced Relocation SIgnallli g 

Transfer (L3 Information^..] 



Figure 5.7.2.1-1. HNB to HNB Handover via lurh interface - UE involved. 

1. The Source HNB evaluates the UE"s access rights against the available neighbour information. If the UE has 
access rights for the Target HNB the Source HNB may decide to send an RNA:CONNECT message (or an 
RNA:DIRECT TRANSFER message if already in SHO) containing an RNSAP:ENHANCED RELOCATION 
REQUEST message to the Target HNB to prepare the Target HNB for relocation. 

2. The Target HNB updates the transport network layer information for any RABs that are to be relocated to it by 
sending an HNBAP:TNL UPDATE REQUEST message to the HNB-GW, the HNB-GW responds with an 
HNBAP:TNL UPDATE RESPONSE. 

3. The Target HNB sends an RNA:DIRECT TRANSFER message containing an RNSAP:ENHANCED 
RELOCATION RESPONSE message back to the Source HNB to indicate that it has successfully prepared the 
relocation. 

4. The Source HNB sends an RNA:DIRECT TRANSFER message containing an RNSAP:RELOCATION 
COMMIT message, to commit the relocation preparation on the Target HNB. This message includes information 
to aid the relocation procedure, these are described in subclause 5.10. 

5. The Source HNB reconfigures the UE to commence the relocation procedure. 

6. At some point later Layer 1 synchronisation is achieved between the UE and the Target HNB. The UE then 
completes the RRC Reconfiguration procedure by sending an RRC:RADIO BEARER RECONFIGURATION 
COMPLETE message to the Target HNB. 

7. The Target HNB indicates to the HNB-GW that the UE has successfully relocated via the HNBAP:UE 
RELOCATION COMPLETE message. The HNB-GW also switches the U-plane to the Target HNB. 

8. The Target HNB initiates the RAB Release Request Procedure to the CN to release unaccepted RABs, if any, 
with an appropriate cause value. 

9. The HNB-GW sends the HNBAP:UE-DEREGISTER to the Source HNB indicating Successful RNSAP 
Relocation with an appropriate cause value. 
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10. The Source HNB sends an RNA:DISCONNECT message containing an RNSAP:ENHANCED RELOCATION 
SIGNALLING TRANSFER message to the Target HNB to transfer any L3 information that the Source HNB 
may have received during the relocation procedure and locally releases any resources it has for the UE. 

NOTE: If the involved HNBs are lurh connected via the HNB-GW, the RNA messages are routed via the HNB- 
GW. 

5.7.2.2 User Plane Handling 

In order to keep the CN unaware of any Intra-GW mobility for RABs operating in support mode (see TS 25.415 [17]), 
which would normally need an lu-UP initialization procedure during relocation, the respective user plane configuration 
(RFCIs, etc.) has to be transferred to the Target HNB without actually carrying out the lu-UP Initialisation procedure 
towards its peer node. Special handling of related control and user data frame sequence numbers has to be applied. 

In order to avoid problems with lu-UP version interworking, the Target HNB shall support at least the same versions of 
lu UP and rate parameters used by the Source HNB. 

In order to allow seamless lu-UP operation from a CN perspective, 

- the Source HNB: 

- shall provide the Target HNB within RANAP ENHANCED RELOCATION INFORMATION REQUEST 
message with 

CS luUP control information needed to allocate luUP instances for those RABs operated in support 
mode. 

- the latest CS lu-UP user-data frame-numbers for UL and DL for all CS RABs operated in support mode 
for which user data frame numbering is based on time together with the time-difference between UL and 
DL packets as received/sent on the source side. 

- shall provide the Target HNB within RANAP RELOCATION INFORMATION message (encapsulated 
within the RNSAP message RELOCATION COMMIT) with 

CS luUP control information needed to allocate luUP instances for those RABs operated in support 
mode, if the luUP configuration of the RABs has changed. 

- the latest CS lu-UP control-data frame-numbers for UL and DL for all CS RABs operated in support 
mode. 

the latest CS lu-UP user-data frame-numbers for UL and DL for all CS RABs operated in support mode 
for which user data frame numbering is based on time together with the time-difference between UL and 
DL packets as received/sent on the source side. 

the last sent DL and last received and forwarded UL user-data frame number for those CS RABs for 
which user-data frame-numbering is based on sent lu UP PDU. 

- the latest PS lu-UP user-data frame-numbers for UL and DL for all applicable PS RABs. 

may start to forward user plane packets towards the Target-HNB for those RABs for which it has decided 
to perform data forwarding, when triggering the execution of the RNSAP Relocation (exact sequence of 
actions is implementation specific). 

not initiate any lu-UP procedure and ignore incoming lu-UP control frames, after having sent the RNSAP 
message RELOCATION COMMIT. 

- the Target-HNB shall 

- after having received the RANAP ENHANCED RELOCATION INFORMATION REQUEST message 

use the information provided by the Source HNB to establish lu-UP instances for receiving user lu-UP 
frames from the Source HNB and may use the information of the last CS lu-UP UL/DL user-data frame 
number as received from the source together with received DL user-data frames to re-install the timing 
and frame-numbering for UL/DL user-data frames once the first DL user data packet is received from the 
Source HNB. 
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use the information provided by the Source HNB to establish lu-UP instances. 

for each CS RAB operated in support mode, use the information of the last CS lu-UP UL/DL user-data 
frame number as received from the source together with received DL user-data frames to re-install the 
timing and frame-numbering for UL/DL user-data frames once the first DL user data packet is received 

not initiate any lu-UP procedure and ignore incoming lu-UP control frames. 

- after having received the HNBAP: TNL UPDATE RESPONSE message from the HNB-GW 

use the information provided by the Source HNB to establish lu-UP instances for receiving user lu-UP 
frames from the HNB-GW and use the information of the last CS lu-UP UL/DL user-data frame number 
as received from the source together with received DL user-data frames to re-install the timing and frame- 
numbering for UL/DL user-data frames once the first DL user data packet is received from the HNB-GW. 

not initiate any lu-UP procedure and ignore incoming lu-UP control frames. 

- after having received the RNSAP message RELOCATION COMMIT 

- use the information of the last CS lu-UP UL control-data frame number as received from the Source HNB 
for the next to be sent UL control-data frame. 

ignore any loss of DL control frames and start respective error handling after the first received DL control 
frame. 

- use the information of the last CS lu-UP UL/DL user-data frame number as received from the source 
together with received DL user-data frames to re-adjust the timing and frame-numbering for UL/DL user- 
data frames, if necessary. 

start lu-UP procedures as necessary (e.g. downlink rate control (due to e.g. local congestion), lu Time 
Alignment). 

- the HNB-GW shall 

- after receipt of the HNB AP:RELOCATION COMPLETE message 

switch the TNL part of the UP completly towards the Target HNB. 

5.7.3 Soft Handover Initiation 

Figure 5.7.3-1 below depicts Soft Handover Initiation in case HNBs are directly lurh-connected. In case of lurh- 
connectivity via the HNB-GW, RNA signalling terminates at the HNB-GW, whereas RNSAP signalling is still 
performed on a HNB-to-HNB basis. 
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UE 



SHNB 



DHNB 



1. RRC Measurement Report 



Decision to setup new RL 



2. RNA CONNECT (UE context id. 



RNSAP Radio Link Setup Request) 

Start Rx 

3. RNA Direct Transfer (UE context id. 



RNSAP Radio Link Setup Response) 

4. RN A Direct Transfer (UE context id. 



RNSAP Radio Link Restore Indication) 



Start Tx 



5. RRC Active Set Update 



6. RRC Active Set Update Complete 



Figure 5.7.3-1. Soft Handover Initiation HNB to HNB. 

1. The Serving HNB (SHNB) receives an RRC measurement report indicating that Soft handover is possible and 
the SHNB decides to setup a RL to the Drift HNB (DHNB). 

2. The SHNB evaluates the UE"s access rights against neighbour information available from the HNB 
Configuration Transfer function. If the UE has access rights for the DHNB, the SHNB may decide to setup a 
new RL and send an RNA:CONNECT message containing an RNSAP:RADIO LINK SETUP REQUEST 
message to the DHNB to set up a radio link at the DHNB. 

3. The DHNB starts receiving from the UE and sends an RNSAP: RADIO LINK SETUP RESPONSE message. 

4. When the radio link is established on the DHNB, the DHNB sends an RNSAP: RADIO LINK RESTORE 
INDICATION message. 

5. The SHNB sends an RRC Active Set Update to the UE 

6. The SHNB receives an RRC Active Set Update Complete from the UE. 



5.7.4 Mobility Access Control 



5.7.4.1 Limitations 

The current version of the specification allows RNSAP relocation and SHO via lurh only for the following scenarios: 
Intra-PLMN Intra-CSG Closed access cell to Closed access cell mobility 
Intra-PLMN Intra-CSG Hybrid access cell to Hybrid access cell mobility 
Open access cell to Open access cell mobiUty. 



5.8 HNB Configuration Transfer 



The HNB Configuration Transfer function provides the means to inform the HNB-GW to provide HNBs with address 
information of neighbour HNBs in order to enable the establishment of lurh connection. The neighbour list is 
maintained in the HNB via interaction with the HMS. The HNB uses the IP addresses received from the HNB-GW to 
connect to neighbour HNBs over lurh. The procedure for HNB Configuration Transfer is shown in Figure 5.8-L 
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HNBi 



HNB-GW 



HNB, 



0. HNBi already operating and registered attlie 
HNB-GW 



3. HNBi identifies HNB2 
as a neighbor 



4. HNB Configuration Transfer Request 
(request HNB2's iurti signalling TNL Address) 



5. HNB Configuration Transfer Response 
(reply HNB2's lurh signalling TNL Address) 



1. HNB2 switches to operational 
mode, scans its environment. 



2. HNB Registration Procedure 



6. The HNBi sets up an lurh connection dependent on the lurh connectivity option configured. 



Figure 5.8-1 HNB Configuration Transfer. 

0. HNBi has already switched to operational mode, has registered at the HNB-GW and is connected to HNBs 
within its reach. 

1 . HNB2 switches to operational mode. 

2. HNB2 registers at the HNB-GW successfully and provides its IP address for direct lurh connectivity. 

3. HNBi identifies a change in its neighbour list, from e.g. detecting HNB2 or via HMS. 

4. HNBi requests the IP addresses of the Target HNB(s) by sending HNBAP HNB Configuration Transfer Request 
to the HNB-GW. 

5. The HNB-GW responds with a HNB Configuration Transfer Response message to the source HNB providing for 
each neighbour HNB requested 

either lurh signalling TNL IP address information indicating the IP address to which the HNB shall setup an 
lurh signalling connection and other information 

or a reason why respective information cannot be provided. 

6. The HNB I sets up an lurh connection towards HNB2. If direct lurh connectivity is applied, HNBi has to establish 
a reUable transport session before issuing the RNA:Iurh Setup procedure. 

If the HNB-GW includes a Ust of lurh signalling TNL addresses in the HNBAP HNB: CONFIGURATION 
TRANSFER RESPONSE message, the HNB establishes lurh connection using the addresses provided in an 
ordered manner starting with the first entry of the list. 

5.9 lurh Setup 
5.9.1 General 

The purpose of this procedure is to setup an lurh connection between two HNBs or between a HNB and a HNB-GW for 
HNB-RNC connectivity, and ensure that they have the necessary information for operation. 
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5.9.2 lurh Setup for direct lurh connectivity between HNBs 



HNBi 



HNB, 



HNB-GW 



1. Establish reliable transport session (SCTP) 



2. RNA lurh Setup Request 



3a. HNBAP Configuration Transfer F^equest 
) 

3b. HNBAP Configuration Transfer Response 



4. RNA lurh Setup Response 



Figure 5.9.2-1 Procedure for lurh Setup - direct lurh connectivity. 

The purpose of this procedure is to establish lurh connectivity between two HNBs and ensure that the application level 
information is available to the two HNBs to interoperate correctly. 

1 . The HNB sets up an SCTP transport session, if required. 

2. HNBi sends an RNA:IURH SETUP REQUEST to HNBj. 

3 If HNB2 does not have configuration information on HNB 1, it triggers a request for the configuration information 
on HNBi from the HNB-GW. 

4. HNB2 responds to HNBi. 

5.9.3 lurin Setup for lurln connectivity between HNBs via tine HNB-GW 



HNBi 



HNB-GW 



HNB, 



1 . Established transport session ( SCTP) 







1 . Established transport session ( SCTP) 


2. RNA:IURH SETUP REQUEST 




2. RNA:IURH SETUP REQUEST 


4. RNA:IURH SETUP RESPONSE 


3a. HNBAP:CONFIGURATION TRANSFER REQUEST 


3b. HNBAP:CONFIGURATION TRANSFER RESPONSE 


^4. RNA:IURH SETUP RESPONSE 











Figure 5.9.3-1 Procedure for lurh Setup-lurh connectivity via the HNB-GW. 
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The purpose of this procedure is to establish lurh connectivity between two HNBs via the HNB-GW and ensure that the 
appHcation level information is available to the two HNBs to interoperate correctly. 

1. HNBi and HNB2 have set up an SCTP transport session towards the HNB-GW at HNB Registration if they both 
support lurh connectivity via the HNB-GW and where triggered by the HNB-GW to establish a transport session 
to it during HNB Registration. 

2. HNBi provides within the RNA:IURH SETUP REQUEST message information which enables the HNB-GW to 
route the message to the HNB2 and to enable the HNB2 to reply via the HNB-GW. 

3 If HNB2 does not have configuration information on HNB 1, it triggers a request for the configuration information 
on HNBi from the HNB-GW. 

4. HNB2 responds with a RNA:IURH SETUP RESPONSE to HNB2 via the HNB-GW. 

5.9.4 lurh Setup between the HNB and the HNB-GW for HNB-RNC 
connectivity 



HNB 



HNB-GW 



RNC 



0. lur interface established between HNB-GW and RNC 



1. At HNB Registration, the HNB establishes a transport session (SCTP) 



2. RNA:IURH SETUP REQUEST 



3. RNA:IURH SETUP RESPONSE 



Figure 5.9.4-1 Procedure for lurh Setup - lurh connectivity between the HNB and the HNB-GW for 

HNB-RNC connectivity. 

The purpose of this procedure is to establish lurh connectivity between the HNB and the HNB-GW for connectivity 
between the HNB and the RNC and ensure that the peer RNC is available through the lurh interface between the HNB 
and the HNB-GW. 

0. An lur interface instance is established between the RNC and the HNB-GW. 

1. At HNB Registration the HNB has set up an SCTP transport session towards the HNB-GW. 

2. HNB sends an RNA:IURH SETUP REQUEST to the HNB-GW to establish the connectivity towards the RNC 
via the HNB-GW. The RNC ID included in the RNA message identifies the peer RNC. 

3. HNB-GW responds with an RNA:IURH SETUP RESPONSE to HNB if the lur interface between the HNB-GW 
and the peer RNC is available. 

5.1 Handling of Source information transfer to Target 

In order to maintain the continuity of UE support during RNSAP Relocation, information must be transferred from the 
Source HNB to the Target HNB. RAB related information to ensure that continuity of User Plane and RAB 
establishment and other non-RAB related information is transferred in the RELOCATION COMMIT message. 
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5.10.1 RAB Related Parameters 

5.10.1.1 User Plane 

During RNSAP Relocation preparation phase, information is provided to the Target HNB in order to allow forwarding 
of user data. For each CS RAB operated in support mode (see TS 25.415 [17] for the definition of 'support mode') luUP 
protocol data is provided to establish a respective luUP instance at the Target HNB in a way that the CN is unaware of 
the RNSAP Relocation. 

During the RNSAP Relocation execution phase, for each CS RAB operated in support mode, final counters of luUP 
user data and control data frames are provided. 

The behaviour of all involved nodes (Source HNB, Target HNB, HNB-GW) is fully specified in subclause 5.7.2.2. 

5.1 0.1 .2 Other parameters 

During Relocation Commit the following information is transferred from the Source HNB to the Target HNB to 
maintain valid data volume reports. 

RAB Data Volume Information, The unsuccessful data report transferred to the target to be accumulated at the target for 
the final Data Volume report on RAB release. 

5.10.2 Non-RAB Related Parameters 

During Relocation Commit the following information is transferred from the Source HNB to the Target HNB to 
continue non-RAB related functionality triggered at the Source HNB: 

Location Reporting parameters are transferred to the Target HNB to ensure continuity of Location Reporting. 

Trace Information parameters are transferred to the Target HNB to ensure continuity of Trace operations. 

The Service Area ID of the source cell is transferred to the target to enable the Target HNB to detect a change of 
service area and report this in the Location Reporting procedures. 



5.8a CS user plane multiplexing 



If the HNB-GW had signalled on the HNB REGISTER ACCEPT a mux port and if the HNB has capability to support 
CS user plane multiplexing, the HNB may send the multiplexed packets to the mux port at the HNB-GW. 

The HNB, for the same UE, shall not send multiplexed packets over multiple ports, i.e., once the HNB chooses to 
multiplex CS user plane packets for a given UE on the uplink, it shall send those multiplexed packets only to the 
assigned mux port on the HNB-GW. For those UEs whose CS user plane packets are not being multiplexed, the HNB 
shall send packets only to the port number assigned via RAB assignment request. 

When the HNB-GW receives multiplexed packet, it shall de-multiplex before sending them to the CN. 

5.9a Inbound IVIobility to HNB 
5.9.1a General 

The following sub-sections describe the mechanism for handling the inbound mobility to HNB via the lu and luh 
interfaces. This mechanism is also applicable to the handover between HNBs under the same HNB-GW. 

5.9.2a Connected Mode Inbound Mobility for CSG UEs to CSG HNBs or to 
Hybrid Cells 

The following figure and accompanying steps describe the inbound mobility procedure for Rel-9 CSG UEs, when the 
Source RAN supplies to the Core Network a CSG id associated with the target HNB. The following is assumed: 
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UE is Rel-9 CSG capable and SIB-reading capable. 

UE is able to provide in the RRC measurement report the cell identity and the CSG-Id (if requested) of the target 
HNB. 

The Source RAN is able to determine the Cell Access Mode of the target HNB. 

NOTE: It is assumed that the network knows whether the target cell is a hybrid cell, e.g. by PSC range for hybrid 
cells. 

The Core network is Release-9 CSG capable and is able to perform access control or membership verification for 
relocated CSG UE. 

The HNB-GW is able to route the incoming relocation to the appropriate target HNB using the target cell 
identity provided in RANAP RELOCATION REQUEST (i.e. Target Cell Id is unique for a HNB in a given 
HNB-GW). 




1. RF C Measurement Report 




HNBGW 



message 




Source 
RAN 



2. Source RAN decides to 
initiate reiocation to target cell 



3. RANAP Relocation Requ red ( 
CSG id, Access Mode ) 



4. Access Control/ 
Membership 
Verification 



5. RA NAP Relocation Request 
CSG id, CSG Membersh p 



6. HNB-GW Triggered UE Registration. 
HNB-GW/HNB validates CSG id 



(IMSI,... 
Status) 



7. Continue with Relocation Procedures 



Figure 5.9.2a-1 : Connected Mode inbound mobility for CSG UEs to CSG HNB or Hybrid Cell. 



1 . The UE is triggered to send an RRC Measurement Report by the rules set by the UTRAN. The Measurement 
Report includes the Cell Identity, CSG id (if requested) of the target HNB as in TS 25.331 [25]. 

2. The Source RAN node makes a decision to relocate the UE session. 

3. The source RAN triggers relocation of the UE session by sending the RANAP RELOCATION REQUIRED 
message to the Core Network. The target RNC-Id, CSG id. Target Cell Id and - for relocation to a hybrid cell 
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Cell Access Mode information along with relocation information are included by the source RAN in the RANAP 
RELOCATION REQUIRED message. 

4. If the target cell is a CSG HNB, the Core Network performs access control on the basis of the CSG ID 
associated with the target cell, as reported to the Core Network (TS 25.413 [9]). Otherwise (if the target is a 
Hybrid Cell), the Core Network performs membership verification and fills the CSG Membership Status IE in 
step 5 to reflect the UE"s membership to the target cell. If the Core Network determines that this relocation is for 
an emergency call then it will allow inbound mobility to CSG cells even if the access control fails and, in case of 
access control failure, the Core Network sets the CSG Membership Status IE to the value 'non-member' in step 5. 

5. The HNB-GW receives a RANAP RELOCATION REQUEST message from the Core Network, including the 
CSG id. Target Cell Id and - for relocation to a hybrid cell - CSG Membership Status. For cases where the 
access control failed for relocation of one or more RABs with a particular ARP value (see TS 23.060 [10]) to a 
hybrid or to a CSG cell the CSG Membership Status IE shall be included and set to 'non-member'. 

6. The steps for HNB-GW Triggered UE Registration are executed between the HNB-GW and the HNB. The 
HNB-GW/HNB vaHdates the CSG id received in the RANAP RELOCATION REQUEST message. If the CSG 
HNB determines that this relocation is for one or more RABs with a particular ARP value (see TS 23.060 [10]) 
and CSG ID validation fails and/or UE is non member then it will accept only those RABs with a particular ARP 
value (see TS 23.060 [10]) and fail the others. 

7. The remainder of the relocation procedure continues normally as documented in TS 25.413 [9], TS 23.060 [10] 

NOTE: Steps 2 to 7, as appropriate, are repeated for the second CN domain when present with the following 

exceptions. The relocation of the 2"** domain shall not trigger an additional registration. The 2°'' RANAP 
Relocation Request shall be carried as RUA Direct Transfer. There is only one Context Id assigned to the 
UE regardless of the number of domains relocated from the source RAN. 

5.9.3a Connected Mode Inbound Mobility for non-CSG UEs to CSG HNBs 
or to Hybrid Cells 

The following figure and accompanying steps describe the inbound mobility procedure for non-CSG UEs, when the 
Source RAN is able to identify the target HNB. The following is assumed: 

UE is non-CSG capable not able to read SIBs for CSG inbound mobility purposes. 

The HNB-GW is able to perform access control or membership verification for the UE 

The HNB-GW is able to route the incoming relocation to the appropriate target HNB. 
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1. RRD Measurement Repoti message 




HNBGW 




3. RA 4AP Relocation Reqi ired 



4. RAIJAP Relocation Request (IMSI, ...) 



5. Access Control/ 
Membership 
Verification 



6. HNB-GW Triggered UE Registration. 




2. Source RAN decides to 
initiate reiocation to target cell 



7. Continue with Relocation Procedures 



Figure 5.9.3a-1 : Connected Mode inbound mobility for non-CSG UEs to CSG HNB or Hybrid Cell. 

1. The UE is triggered to send an RRC Measurement Report by the rules set by the UTRAN as in TS 25.331[25]. 

2. The Source RAN node makes a decision to relocate the UE session. 

3. The source RAN triggers relocation of the UE session by sending the RANAP RELOCATION REQUIRED 
message to the Core Network. The target RNC-Id and Target Cell Id are included by the source RAN in the 
RANAP RELOCATION REQUIRED message. The source RAN shall not include target CSG ID and the Cell 
Access Mode in the RELOCATION REQUIRED message. 

4. The Core Network shall not perform any access control or membership verification for the UE and it shall not 
include target CSG ID and CSG Membership Status in the RELOCATION REQUEST message. 

5. The HNB-GW receives a RANAP RELOCATION REQUEST message not including the target CSG ID and the 
CSG Membership Status. The HNB-GW shall perform access control (in case of CSG cells) or membership 
verification (in case of Hybrid cells) for the UE. If the relocation is towards a hybrid cell the HNB-GW may 
include the CSG Membership Status in the RUA Connect message. If the HNB-GW determines that this 
relocation is for one or more RABs with a particular ARP value (see TS 23.060 [10]) then it will allow inbound 
mobility to CSG cells even if the access control fails and, in case of access control failure, the HNB-GW sets the 
CSG Membership Status IE to the value 'non-member' in the RUA Connect message. 

6. The steps for HNB-GW Triggered UE Registration are executed between the HNB-GW and the HNB. If the 
CSG HNB determines that this relocation is for one or more RABs with a particular ARP value (see TS 23.060 
[10]) and the UE is non member then it will accept only those RABs with a particular ARP value (see TS 23.060 
[10]) and ensure that the others are not continued in the target cell. 
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7. The remainder of the relocation procedure continues normally as documented in TS 25.413 [9], TS 23.060 [10]. 

NOTE: Steps 2 to 7, as appropriate, are repeated for the second CN domain when present with the following 

exceptions. The relocation of the 2"*^ domain shall not trigger an additional registration. The 2""* RANAP 
Relocation Request shall be carried as RUA Direct Transfer. There is only one Context Id assigned to the 
UE regardless of the number of domains relocated from the source RAN. 

5.9.4a Connected Mode Inbound Mobility to open access HNBs 

The following figure and accompanying steps describe the inbound mobility procedure when the Source RAN is able to 
identify the target HNB. The following is assumed: 

• The HNB-GW is able to route the incoming relocation to the appropriate target HNB. 




1. RR[^ Measurement Repon message 




HNBGW 




3. RA 4AP Relocation Reqi ired 



4. RAIJAP Relocation Request (IMSI, ...) 



6. HNB-GW Triggered UE Registration. 



Source 
RAN 



2. Source RAN decides to 
initiate relocation to target cell 



7. Continue with Relocation Procedures 



Figure 5.9.4a-1 : Connected Mode inbound mobility to open access HNBs. 

1. The UE is triggered to send an RRC Measurement Report by the rules set by the UTRAN as in TS 25.331[25]. 

2. The Source RAN node makes a decision to relocate the UE session. 

3. The source RAN triggers relocation of the UE session by sending the RANAP RELOCATION REQUIRED 
message to the Core Network. The target RNC-Id and Target Cell Id are included by the source RAN in the 
RANAP RELOCATION REQUIRED message. The source RAN shall not include target CSG ID and the Cell 
Access Mode in the RELOCATION REQUIRED message. 

4. The Core Network shall not perform any access control or membership verification for the UE and it shall not 
include target CSG ID and CSG Membership Status in the RELOCATION REQUEST message. 
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5. The HNB-GW receives a RANAP RELOCATION REQUEST message not including the target CSG ID and the 
CSG Membership Status. 

6. The steps for HNB-GW Triggered UE Registration are executed between the HNB-GW and the HNB. 

7. The remainder of the relocation procedure continues normally as documented in TS 25.413 [9], TS 23.060 [10] 

NOTE: Steps 2 to 7, as appropriate, are repeated for the second CN domain when present with the following 

exceptions. The relocation of the 2"** domain shall not trigger an additional registration. The 2°'' RANAP 
Relocation Request shall be carried as RUA Direct Transfer. There is only one Context Id assigned to the 
UE regardless of the number of domains relocated from the source RAN. 

5.10a CSG Subscription Expiry 

Case of CSG UEs: 

If the CN has signalled CSG membership update to the HNB: 

If the UE is served by a CSG cell, and is no longer a member of the CSG cell, the HNB may initiate a handover 
to another cell. If the UE is not handed over, or handover is not initiated, the HNB should request the release of 
lu connection (s) with an appropriate cause. The CN initiates lu release after a configurable time, if the UE is not 
handed over or released by the CSG cell (TS 23.060 [10]). 

If the UE is served by a Hybrid cell, the HNB may use the new membership information to perform 
differentiated treatment for member and non-member UEs. 

Case of non-CSG UEs: 

If the HNB-GW has signalled CSG membership update to the HNB: 

If the UE is served by a CSG cell, and is no longer a member of the CSG cell, the HNB may initiate a handover 
to another cell. If the UE is not handed over, or handover is not initiated, the HNB should request the release of 
lu connection (s) with an appropriate cause. The HNB-GW shall initiate UE De-Registration after a configurable 
time, if the UE is not handed over or released by the serving HNB. 

If the UE is served by a Hybrid cell, the HNB may use the new membership information to perform 
differentiated treatment for member and non-member UEs. 

5.1 1 Connectivity between HNB and RNC via HNB-GW for 
RNSAP signalling 

5.11.1 General 

The following sub-sections describe the mechanism for handling Enhanced Relocation and Soft Handover between 
RNC and HNB via the HNB-GW. 

5.1 1 .2 Enhanced Relocation between HNB and RNC via HNB-GW 
5.1 1 .2.1 Enhanced Relocation from Open Access and Hybrid HNBs to RNC 

The mobility procedure described in Figure 5. 11. 2.2-1 requires the HNB-GW to route the incoming Enhanced 
Relocation signalling from the Source HNB to the appropriate Target RNC indicated by an RNC -ID provided within the 
RNA:CONNECT message. 
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Complete 
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Figure 5.11.2.1-1: Enhanced Relocation from Open Access and Hybrid HNBs to RNC. 

0-9. The RNSAP signalling for preparing and executing the relocation between the HNB and the RNC follows the 
standardised Enhanced SRNS Relocation procedure as defined between two RNCs (see TS 23.060 [10]). 

10-13. After the UE has completed RRC signalling for the relocation, the RANAP: ENHANCED RELOCATION 
COMPLETE REQUEST message is sent from the Target RNC to the MSC/SGSN. The MSC/SGSN replies with 
a RANAP: ENHANCED RELCOATION COMPLETE RESPONSE message. In case of CS domain, the target 
RNC sends RANAP Enhanced Relocation Complete Confirm message to the MSC after completion of UP 
initialization. 

14-17. Subsequently the CN initiates lu Release procedure to release the source-side Iu(h) resources. 

5.1 1 .2.2 Enhanced Relocation from RNC to Open Access HNBs for CSG UEs 

The mobility procedure described in Figure 5.11.2.2-1 requires the following: 

The Source RNC is able to determine the target HNB and its Cell Access Mode based on UE measurements. 

NOTE: It is assumed that the source RNC has a priori knowledge whether the target cell is an open mode cell or 
not, e.g., via the PSC range configured for open cells in this part of the network 

The HNB-GW is able to route the incoming Enhanced Relocation signalling from the Source RNC to the 
appropriate target HNB using the target cell identity provided in RNSAP: ENHANCED RELOCATION 
REQUEST. 
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Figure 5.11.2.2-1 : Enhanced Relocation from RNC to Open Access HNB for CSG UEs. 

0-9. The RNSAP signalling for preparing and executing the relocation between the RNC and the HNB follows the 
standardised Enhanced SRNS Relocation procedure as defined between two RNCs (see TS 23.060 [10]). 

10-12. After the UE has completed RRC signalling for the relocation, the RANAP: ENHANCED RELOCATION 
COMPLETE REQUEST message is sent from target HNB to HNB GW (via luh) and forwarded from HNB GW 
to MSC/SGSN (via lu). 

13-14. After the reception of RANAP: ENHANCED RELOCATION COMPLETE REQUEST the MSC/SGSN 
replies with RANAP: ENHANCED RELOCATION COMPLETE RESPONSE. The HNB-GW forwards this 
message to the target HNB (via luh). 

15-16. In case of CS domain, the target HNB sends RANAP Enhanced Relocation Complete Confirm message to 
the MSC after completion of UP initialization. 

17-18. The MSC/SGSN mandates the RNC to release the former lu resources. 
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5.1 1 .2.3 Enhanced Relocation from RNC to Hybrid HNB for CSG UEs 

The mobility procedure described in Figure 5.1 1.2.3-1 requires the following: 

- The UE is Rel-9 CSG capable and SIB-reading capable. 

The Source RNC is able to determine the Cell Access Mode of the target HNB. 

NOTE: It is assumed that the source RNC is able to initiate and interpret respective UE measurements and may in 
addition have an a priori knowledge whether the target cell is a hybrid cell, e.g., via the PSC range 
configured for hybrid cells in this part of the network. 

The HNB-GW is able to route the incoming Enhanced Relocation signalling from the Source RNC to the 
appropriate target HNB using the target cell identity provided in RNSAP: ENHANCED RELOCATION 
REQUEST. 
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Figure 5.11.2.3-1: Enhanced Relocation from RNC to Hybrid HNB for CSG UEs. 

0-9. RNSAP Signalling for preparing and executing the relocation between the RNC and the HNB follows the 
currently standardised Enhanced SRNS Relocation procedure as defined between two RNCs (See TS 23.060 
[10]). 

10-11. Upon successful relocation preparation and RRC signalling completion, the UE is temporarily admitted in the 
target hybrid cell according to the access status declared by the UE and provided by the Source RNC to the 
Target HNB within the CSG Membership Status IE included in the RNSAP: ENHANCED RELOCATION 
REQUEST message. The UE may be admitted as its reported CSG membership status until the outcomes of 
membership verification are received from CN. 
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12-13. The RANAP: ENHANCED RELOCATION COMPLETE REQUEST message is sent from target HNB to 
HNB GW (via luh) and forwarded from HNB GW to MSC/SGSN (via lu). The RANAP: ENHANCED 
RELOCATION COMPLETE REQUEST includes CSG ID IE and Cell Access Mode IE of the target cell. 

14-16. After reception of RANAP: ENHANCED RELOCATION COMPLETE REQUEST the MSC/SGSN 
performs membership verification of the relocated UE according to CSG ID IE and Cell Access Mode IE 
received. The MSC/SGSN replies to the HNB GW with RANAP: ENHANCED RELOCATION COMPLETE 
RESPONSE containing the CSG Membership Status IE. The RANAP: ENHANCED RELOCATION 
COMPLETE RESPONSE message is forwarded from HNB GW to target HNB (via luh). The target HNB may 
apply the appropriate level of prioritisation to the UE according to the CSG Membership Status IE received. 

17-18. In case of CS domain, the target HNB sends RANAP Enhanced Relocation Complete Confirm message to 
the MSC after completion of UP initialization. 

19-20. The MSC/SGSN requests the RNC to release the source-side lu resources. 

5. 11 .3 Soft Handover between HNB and RNC via HNB-GW 
5.1 1 .3.1 Soft Handover from HNB to RNC 

Mobility from HNB cells (hybrid or open access) to macro RNC using Soft Handover (SHO) follows the same 
principles as mobility between macro cells and uses an lur interface established between HNB and macro RNC via the 
HNB-GW to support RNSAP signalHng. 

The HNB-GW acts as a single RNC towards the macro RNC (as it does towards the CN) and therefore acts as a 
concentrator for HNB-RNC connectivity via the HNB-GW. 

For this case there is no involvement of the CN in the SHO operations, as there is no access control/membership 
verification needed for SHO to a macro RNC. 

The HNB acts as a SRNC and requests resources from the macro RNC, however this may happen only in case of HNBs 
deployed in a secure and operator controlled way (coordinated deployment) and, in this case, it is managed by the CAC 
oftheDRNC. 

Figure 5.11.3.1-1 shows the sequence of messages involved. 
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Radio Link Setup Request] 



5. RNA Direct Transfer 

[RNSAP Radio Link Setup 

Response] 



7. RNA Direct Transfer 
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3. RNSAP Radio Link Setup 
Request 



4. RNSAP Radio Link Setup 
Response 



6. RNSAP Radio Link Restore 
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Figure 5.11.3.1-1: Soft Handover HNB to RNC via HNB-GW. 

1 . HNB determines that a RL can be established to a macro RNC cell. 
2-7. Normal RL setup procedure between HNB and RNC via the HNB-GW. 

5.1 1 .3.2 Soft Handover from RNC to Open or Hybrid Access HNB 

Mobility from macro cells to Open or Hybrid Access HNB cells using Soft Handover follows the same principles as 
mobility between macro cells and uses an lur interface established between the HNB and the macro RNC via the HNB- 
GW to support RNSAP signalhng. 

The HNB-GW acts as a single RNC towards the macro RNC (as it does towards the CN) and therefore acts as a 
concentrator for HNB-RNC connectivity via the HNB-GW. 

For this case of open or hybrid access HNB, there is no involvement of the CN in the SHO operations. For the case of 
SHO to hybrid access HNB, if supported, the Radio Link is established assuming the UE is non-member. 

The macro RNC acting as SRNC requests resources from the HNB, it is managed by the CAC of the HNB. 

Figure 5.11.3.2-1 shows the sequence of messages involved. 
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Figure 5.11.3.2-1 : Soft Handover from RNC to Open or Hybrid Access HNB via HNB-GW. 

1 . RNC determines that a RL can be established to a HNB celL 

2-7. Normal RL setup procedure between RNC and HNB via the HNB-GW. For Hybrid cells, if supported, the 
Radio Link is established assuming the UE is a non-member. 

5.12 Fixed Broadband Access network Interworking 

Case of CS sessions: 

The HNB signals the Tunnel Information to the HNB GW via the HNB Registration procedure. The Tunnel Information 
includes HNB IP address and the UDP port number if NAT/NAPT is detected. The HNB-GW establishes and manages 
the S15 session by the tunnel information and RAB information as specified in TS 23.139 [36]. 

Case of PS sessions: 

The HNB signals the Tunnel Information to the SGSN via INITIAL UE MESSAGE message, RELOCATION 
COMPLETE message, and ENHANCED RELOCATION COMPLETE REQUEST message. The Tunnel Information 
includes HNB IP address and the UDP port number if NAT/NAPT is detected. 
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6 Requirements for O&M 

6.1 O&MforHNB 

6.1 .1 Provisioning Procedure for HNB 



HNB 



1. Establish Secure tunnel 



Security 
Gateway 



HMS 



2. Location verification, HNB GW discovery, 
HNB Provisioning using TR-069 



r r 

3. Reliable Transport setup (SCTP) 



HNBGW 



4. HNB Registration procedure commences 



Figure 6.1.1-1. Provisioning procedure for l-INB. 

1 . A secure tunnel is established from the HNB to the Security gateway. 

2. Location verification shall be performed by the HMS based on information sent by the HNB (e.g. macro 
neighbour cell scans, global navigational satellite system type of information etc.). HMS determines the serving 
elements and provides the HNB-GW, HMS and Security Gateway to the HNB. The HMS also provisions 
configuration parameters to the HNB only after successful location verification in the HMS. 

NOTE: Steps 3 & 4 are shown only for completeness. Security Gateway and HMS are shown to highlight the 
general architecture. 

NOTE: In the event information required for verifying location are not available (for example, no macro 

neighbour cells, no GNSS, no DSL line ID etc. available), HNB-GW discovery may be based on specific 
operator and/or regulatory policies. 

6.1.2 Location Verification 



6.1.2.1 



General 



During location verification, the HNB reports its location information to the HMS. The HMS in turn examines the 
provided information and verifies the HNB"s location. There are 3 possible types of information for this purpose: 

1 . Macro-cell Information 

2. GNSS location information 

3. Broadband connection information, provided that the resulting location information is at least as accurate as 
location determination based on macro-cell coverage information, whether or not there is macro-cell coverage 
available at the location of the HNB (e.g. as determined by point 1 . above). 

NOTE: Not all of this information is mandatory. In fact, the type of reported information is based on factors such 
as the physical environment in which the HNB is installed and/or possible variations in the HNB"s HW 
and SW implementation. 



6.1.2.2 



Macro-cell Information 



6.1.2.2.1 



General 



The HNB is expected to have a radio environment measurement capability. This includes capturing the following type 
of information from the surrounding environment. 
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a) UTRAN cell information 

RF level information 
Broadcast information 

b) GSM cell information 

RF level information 
Broadcast information 

6.1 .2.2.2 UTRAN Cell Information 

The information in the following table is reported by the HNB to the HMS for each UTRAN cell detected. 

Table 6.1.2.2.2-1. UTRAN Cell Information. 



Information 


Description / Note 


Presence 


3GPP Reference 


RF 
information 


UARFCNDL 


UARFCN (DL) 


M 


TS 25.104 [23] 

SGC 5 4 

TS 36.642 [24] sec. 

6.3.11 


CPICHRSCP 


RSCP of CPICH 


M 




PSC 


Primary Scrambling Code 


M 


TS 32.642 [24] sec. 
6.3.11 


Broadcast 
information 


PLMN Type 


« GSM-MAP » or « ANSI- 
41 » 


M 


TS 25.331 [25] 
sec.10.3.1.12 


MCC 


Mobile Country Code 


M 


TS 24.008 [26], 
TS 32.642 [24] sec. 
6.3.10 


MNC 


Mobile Network Code 


M 


TS 24.008 [26], 
TS 32.642 [24] sec. 
6.3.10 


LAC 


Location Area Code 


M 


TS 24.008 [26] 
sec. 10. 5.1. 3, 
TS 32.642 [24] sec. 
6.3.10 


RAG 


Routing Area Code 


M 


TS 24.008 [26], 

sec.10.5.1.12.3, 

TS 25.413 [9], 

sec.9.2.3.7, 

TS 32.642 [24] sec. 

6.3.10 


CelllD 


Cell ID 


M 


TS 25.331 [25] 
sec.10.3.2.2 


CSG Cell Info 


<detail per Rel.8 RRC speo 





Applicable to Rel.8 
compliant cell only. 



6.1.2.2.3 GSM Cell Information 

The information in the following table is reported by the HNB to the HMS for each GSM cell detected. 
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Table 6.1.2.2.3-1. GSM Cell Information. 



Information 


Description / Note 


Presence 


3GPP Reference 


RF 
information 


ARFCN 


Channel number 


M 


TS 32.652 [27] 
sec. 6.3.5 


BCCHRSSI 


RSSI of the BCCH carrier. 


M 


TS 32.652 [27] 
sec. 6.3.5 


BSIC 


Base Station ID Code 


M 


TS 32.652 [27] 
sec. 6.3.5 


Broadcast 
Information 


MCC 


Mobile Country Code 


M 


TS 32.652 [27] 
sec. 6.3.5 


MNC 


Mobile Network Code 


M 


TS 32.652 [27] 
sec. 6.3.5 


LAC 


Location Area Code 


M 


TS 32.652 [27] 
sec. 6.3.5 


RAG 


Routing Area Code 


M 


TS 32.652 [27] 
sec. 6.3.5 


CelllD 


Cell ID 


M 


TS 32.652 [27] 
sec. 6.3.5 



6.1.2.3 



GNSS Location Information 



This information consists of, at minimum, latitude and longitude detected by the GNSS receiver (e.g. GPS receiver), if 
the HNB implementation includes this functionality. 



6.1.2.4 



Broadband Connection Information 



This information consists of the information associated with the broadband connection (e.g. DSL) the HNB is 
connected with: 1) public IP address assigned to the RGW (e.g. DSL-GW/router), and 2) line identifier to which the 
RGW is connected with (e.g. DSL line ID) as seen on the broadband service provider. These are applicable only when 
this information is available to the HNB, and only when the resulting location information is at least as accurate as 
location determination based on macro-cell coverage information, whether or not there is macro-cell coverage available 
at the location of the HNB (e.g. as determined by clause 6.1.2.2 above). 

6.1.3 HNB-GW Discovery 

During the HNB-GW Discovery procedure, the HMS provides the HNB with 3 identities as shown in the following 
table. The information may be either IP address or FQDN to be resolved by DNS. 

Table 6.1.3-1. HNB-GW Discovery Information. 



Parameter 


Description / Note 


Presence 


3GPP Reference 


Serving HMS ID 


One or more IDs may be provided 


M 




Serving SeGW ID 


One or more IDs may be provided 


M 




Serving HNB-GW ID 


One or more IDs may be provided 


M 





6.1.4 HNB Provisioning 



6.1.4.1 



General 



During the HNB Provisioning procedure, the HMS transfers the HNB configuration information to the HNB. This 
includes 3 types of parameters: 

1 . CN level parameters 

2. RAN level parameters 

3. RF level parameters 
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NOTE: The HNB may have auto-configuration capabihties, such that the HMS sends a list/range of values to the 
HNB, which selects (and returns to HMS) a single value, also based on the information collected 
measuring the radio environment. The HMS may also provide control parameters of the auto- 
configuration process. 



6.1.4.2 



CN Level Parameters 



Table 6.1.4.2-1. CN Level Parameters. 



Parameter 


Description / Note 


Presence 


3GPP Reference 


PLMN Type 


'GSM-MAP'or'ANSI-41' 


M 


TS 25.331 [25] sec. 
10.3.1.12 


MCC 


Mobile Country Code 


M 


TS 24.008 [26], 

TS 32.642 [24] sec. 
6.3.8 


MNC 


Mobile Network Code 


M 


TS 24.008 [26], 

TS 32.642 [24] sec. 
6.3.8 


LAC 


Location Area Code (one or more LACs 
may be provided) 


M 
(Note1) 


TS 24.008 [26] 
sec.10.5.1.3, 

TS 32.642 [24] sec. 
6.3.9 


SAC 


Service Area Code 


M 


TS 25.413 [9] 
sec.9.2.3.9, 

TS 32.642 [24] sec. 
6.3.9 


T3212 


Periodic LAU timer (CS domain) 


M 


TS 24.008 [26] sec. 
10.5.1.12.2 


ATT 


Attach-detach allowed (CS domain) 


M 


TS 24.008 [26] sec. 
10.5.1.12.2 


RAC 


Routing area code (PS domain) (one or 
more RACs may be provided) 


M 
(Note1) 


TS 24.008 [26] 
sec.10.5.1.12.3, 
TS 25.413 [9] 
sec.9.2.3.7, 

TS 32.642 [24] sec. 
6.3.9 


NMO 


Network Mode of Operation (Gs i/f) 


M 


TS 24.008 [26] sec. 
10.5.1.12.3 


Equivalent PLMN ID 


List of one or more equivalent PLMN ID 
(MCC + MNC) 




(Note 2) 


TS 24.008 [26] sec. 
10.5.1.13 


Allowed IMSI list 


For access control or membership 
verification purposes. 




(Note 3) 


TS 24.008 [26] sec. 
10.5.1.4 


CSG Cell Info 


CSG Capability Indication, 

CSG Id, in case the Cell is CSG capable 

<any further detail per Rel.8 RRC speo 


M 


Applicable to Rel.8 
compliant cell only. 


HNB Location 
Information 


Location information (Geographical 
coordinates, Uncertainty code) 





TS 25.413 [9] sec. 
9.2.3.11 


SAI for broadcast 


Service Area for broadcast 


M 


TS 25.419 [12] sec. 
9.2.11 


Note 1 : May be a list/range of values in case the HNB has auto-configuration capabilities. 
Note 2: This information is operator-dependent based on its circumstance. 

Note 3: ACL is an optional function at HNB. This information is provided if this function is enabled in 
the HNB. 
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6.1.4.3 



RAN Level Parameters 



Table 6.1.4.3-1. RAN Level Parameters. 



Parameter 


Description 


Presence 


3GPP Reference 


RNCIDforHNB 


RNC ID used by HNB 


M 


TS 32.642 [24] 










sec. 6.3.8 


Cell ID 




28-bit 'Cell ID'inSIB3 


M 


TS 25.331 [25] 
sec. 10.3.2.2 


HSPA related 


HSflag 


Whether 

HSDPA/HSUPA is used 
or not 





TS 32.642 [24] 
sec. 6.3.9 


HCS related 


UseOfHCS 

HCSPrio 

QHCS 




M 


TS 25.331 [25] 
sec. 10.3.7.47 and 
10.3.7.12, 
TS 32.642 [24] 
sec. 6.3.9 


Cell selection 


Quality measure 


CPICH Ec/NO or RSCP 


Q (Note 


TS 25.331 [25] 


/ reselection 


QqualMin 


if Ec/NO is used 


1) 


sec. 10.3.2.3 and 


related 


QqualMin-offset 






10.3.2.4, 




QrxlevMin 


if RSCP is used 




TS 32.642 [24] 




QrxlevMin-offset 






sec. 6.3.9, 




Sintrasearch 






TS 25.304 [29] 




Sintersearch 










SsearchRAT 










SsearchHCS 










Treselections 










UETxPwrMaxRACH 










QHystI 








Intra Freq 


Filter coefficient 


Filter coefficient 


Q (Note 


TS 25.331 [25] 


Measurement 


Measurement quantity for freq 


CPICH Ec/No, CPICH 


1) 


sec. 10.3.7.38 and 


Related 


quality estimate 
Hysteresis for event 1x 
Threshold for event 1x 
TimetoTriggerfor event 1x 
Weighting factor for event 1x 
Reporting Range 
Triggering Condition 


RSCP, or pathless 
'x' in 1x includes 
applicable events from 
lAto U 




10.3.7.39 


Inter-Freq 


Filter coefficient 


Filter coefficient 


Q (Note 


TS 25.331 [25] 


Measurement 


Measurement quantity for freq 


CPICH Ec/No, CPICH 


1) 


sec. 10.3.7.1 8 and 


Related 


quality estimate 
Hysteresis for event 2x 
Threshold for event 2x 
TimetoTrigger for event 2x 
Weighting factor for event 2x 


RSCP 

'x' in 2x includes 
applicable events from 
2A to 2F 




10.3.7.19 


Inter-RAT 


Filter coefficient 


Filter coefficient 


Q (Note 


TS 25.331 [25] 


Measurement 


BSIC verification required 


'required' /'not required' 


1) 


sec. 10.3.7.29 and 


Related 


Hysteresis for event 3x 
Threshold for event 3x 
TimetoTrigger for event 3x 
Weighting factor for event 3x 


'x' in 3x includes 
applicable events from 
3A to 3D 




10.3.7.30 


RRC related 


N30x, N31x 


RRC constants 


Q (Note 


TS 25.331 [25] 




T30x, T31x, T320 


RRC timers 


1) 


sec. 10.3.3.43 and 
10.3.3.44 


Neighbour list 


RNCID 


Defined for each intra- 


Q (Note 


TS 32.642 [24] 


(UTRA Intra- 


C-ld 


freq cells 


2) 


sec. 6.3.10, 


Freq cell info 


LAC 


C-ld is either 12 or 16 




TS 25.401 [4] sec. 


list) 


RAC 


bits depending on 




6.1, 




PSC 


RNCID length. 




TS 25.413 [9] sec. 
9.2.1.28 


Neighbour list 


RNCID 


Defined for each inter- 


Q (Note 


TS 32.642 [24] 


(UTRA Inter- 


C-ld 


freq cells 


2) 


sec. 6.3.10, 


Freq cell info 


LAC 


C-ld is either 12 or 16 




TS 25.401 [4] sec. 


list) 


RAC 


bits depending on 




6.1, 




UARFCN (DL) 


RNCID length 




TS 25.413 [9] sec. 




PSC 






9.2.1.28 
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Neighbour list 
(GERAN cell 
Info list) 



CellD 
BSIC 

Bandlndicator 
BCCHARFCN 



Defined for each inter- 
RAT cells (assume GSM 
cell only). 



O (Note 
2) 



TS 32.652 [27] 
sec. 6.3.5 



Note 1 : 



Note 2: 



Marked as optional based on the operator preference on the extent of provisioning that the HMS 
performs to the HNB vs. the level of autonomy that HNB has for auto-configuration. In case this IE is 
absent, default value is assumed (additional implication is that HNB has a set of default parameter 
values). 

Marked as optional due to several implications: 1) there may be no suitable neighbour cell available 
based on the RF scanning procedure described earlier, 2) based on operator deployment policy (e.g. 
dedicated RF channel for HNB layer vs. macro layer), and 3) operator preference on the extent of 
provisioning that the HMS performs to the HNB vs. the level of autonomy that HNB has for auto- 
configuration. Regarding 3) above, this may include capabilities such as the HMS to add or remove 
neighbour cells initially detected by the HNB during the radio environment scanning process, and the 
HNB to extend the received Neighbour list based on auto-configuration capabilities. 



6.1.4.4 



RF Level Parameters 



Table 6.1.4.4-1. RF Level Parameters. 



Parameter 


Description / Note 


Presence 


3GPP Reference 


UARFCN (DL) 


Frequency channel number (one or more 
UARFCNs may be provided) 




(Notel) 


TS 25.101 [28] sec. 

5.4, 

TS 25.104 [23] sec. 

5.4, 

TS 32.642 [24] sec. 

6.3.11 


PSC 


Primary scrambling code (one or more 
PSCs may be provided) 




(Notel) 


TS 32.642 [24] sec. 
6.3.11 


MaxHNBTxPower 


Maximum allowed Tx power of the HNB. 




(Note 1 ) 


TS 25.104 [23] sec. 

6.2, 

TS 32.642 [24] sec. 

6.3.9 


MaxULTxPower 


The parameter defines the maximum 
transmission power level a UE can use on 
PRACH. 




(Notel) 


TS 25.101 [28] sec. 

6.2, 

TS 32.642 [24] sec. 

6.3.9 


P-CPICHPower 


Transmission power of Primary CPICH (DL 
config). This may be either a specific value 
or a range (min / max) of values. 




(Notel) 


TS 32.642 [24] sec. 
6.3.11 


P-SCHPower 


Primary SCH power offset (DL config) 




(Notel) 


TS 32.642 [24] sec. 
6.3.11 


S-SCHPower 


Secondary SCH power offset (DL config) 




(Notel) 


TS 32.642 [24] sec. 
6.3.11 


BCHPower 


BCH power offset (DL config) 




(Notel) 


TS 32.642 [24] sec. 
6.3.11 


AlCHPower 


AICH power offset (DL config, BCCH info) 



(Note 1 ) 


TS 25.331 [25] sec. 

10.3.6.3, 

TS 32.642 [24] sec. 

6.3.11 


PICHPower 


PICH power offset (DL config, BCCH info) 



(Note 1 ) 


TS 25.331 [25] sec. 

10.3.6.50, 

TS 32.642 [24] sec. 

6.3.9 


PCHPower 


PCH power offset (DL config, BCCH info) 




(Notel) 


TS 32.642 [24] sec. 
6.3.9 


EACH Power 


EACH power offset (DL config, BCCH info) 




(Notel) 


TS 32.642 [24] sec. 
6.3.9 


Note 1 : Marked as optional based on the operator preference on the extent of provisioning that the 
HMS performs to the HNB vs. the level of autonomy that HNB has for auto-configuration. In 
case this IE is absent, it is assumed that the HNB will derive the suitable value based on its 
auto-configuration capability. In case this IE is a list/range of values, the HNB will choose a 
single value based on its auto-configuration capability. UARFCN UL may be automatically 
determined by the HNB upon UARFCN DL (basing on standard duplex configuration and 
country-specific spectrum allocation). 
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6.2 O&M for HNB-GW 

No requirements have been identified. 
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luh interface protocol structure 



7.1 General 

Figure 7.2-1 shows the Control Plane and the User Plane protocol structures over the luh interface. For the control 
plane, the HNBAP protocol provides the signalling service between the HNB and the HNB-GW required to fulfil the 
functions described in TS 25.469 [3]. 

RUA provides the signalling service between the HNB and the HNB-GW that is required to fulfil the functions 
described in TS 25.468 [2]. 

The payload protocol identifier (PPl) field in SCTP (IETF RFC 4960 [6]) is set to the value 19 assigned by lANA for 
use with the RUA protocol. In addition, the value 20 is assigned for the PPl for HNBAP. The value 31 is assigned for 
the PPl for SABP. The multiplexing protocol as specified in TS 25.444 [8] provides the means to multiplex CS user 
plane on the uplink. 

The destination port number field in SCTP (IETF RFC 4960 [6]) is set to the value 29169 assigned by lANA for setup 
of the common SCTP association in HNBAP, RUA and SABP. 

For lurh there shall be an SCTP association for each direct lurh interface between HNBs. For operation via the HNB- 
GW there shall be a single SCTP association common to all lurh interface instances. This association shall be separate 
from the luh SCTP association established between the HNB and the HNB-GW. 

The payload protocol identifier (PPl) field in IETF RFC 4960 [6] is set to the value 42 registered by lANA for the use 
with the RNA protocol. 

The destination port number field in IETF RFC 4960 [6] is set to the value 25471 assigned by lANA for setup of the 
SCTP association in RNA. 

7.2 luh 

Figure 7.2-1 shows the protocol structure for luh, following the structure described in TS 25.401 [4]. 
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Radio 

Network 

Layer 



Transport 

Network 

Layer 



Control Plane 



RANAP 



HNBAP 



SAB? 



RUA 



v_ 






_^ 



Transport 
User 



Network 
Plane 



SCTP 



IP 



Data Link 



Transport Network 
Control Plane (void) 



Physical Layer 



User Plane 



lu UP Protocol 
Layer ^' 



Transport 
User 



CS: RTF/ 
RTCP" 



Network 
Plane 



CS: 

MUX 



PS: 

GTP-U 



UDP/IP 



Data Link 



Note 1) RTCP is optional. 

Note 2) lu UP is terminated in CN and HNB only (i.e. not in the HNB GW) 



Figure 7.2-1 . luh-lnterface Protocol Stack. 

7.3 lurh 

Figure 7.3-1 shows the protocol structure for lurh, following the structure described in TS 25.401 [4]. 
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Figure 7.3-1. lurh-lnterface Protocol Stack. 

NOTE 1: RTCP is optional 

NOTE 2: as specified in TS 25.425 [21] and TS 25.427 [22] 

NOTE 3: as specified in TS 25.415 [17] 



7.3.1 



lurh-lnterface Control Plane Protocol Stack 



The figures below show the control plane protocol stack for lurh both for direct connectivity between HNBs and for 
connectivity between a HNB and a macro RNC via the HNB-GW. 

Figure 7.3.1-1 shows the control plane protocol stack for the direct lurh-connectivity option between HNBs. 

NOTE: The option that lurh signalling traffic may be routed on IP level via the HNB-GW is depicted by the 
optional protocol entity boxes within the routing function. 
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HNBi 



RNSAP 



RNA 
SCTP 



IP 
Data Link 



PHY 



IP routing function 



HNB, 



RNSAP 
RNA 



SCTP 



IP 



Data Link 
PHY 



Figure 7.3.1-1. lurh-lnterface Protocol Stack for direct lurh-connectivity between HNBs. 

Figure 7.3.1-2 shows the control plane protocol stack for the lurh connectivity between HNBs via the HNB-GW. 



HNBi 



RNSAP 



RNA 



SCTP 
IP 



Data Link 
PHY 



HNB-GW 



HNB2 
-*\ RNSAP 



RNA 



RNA 



SCTP 
IP 



SCTP 
IP 



Data Link 
PHY 



Data Link 
PHY 



RNA 



SCTP 



IP 



Data Link 



PHY 



Figure 7.3.1-2. lurh-lnterface Protocol Stack for lurh-connectivity between HNBs via the HNB-GW. 

Figure 7.3.1-3 shows the control plane protocol stack for connectivity between a HNB and a macro RNC via the HNB- 
GW. 



HNB 



RNSAP 



RNA 



SCTP 
IP 



Data Link 
PHY 



HNB-GW 

Interworkin^functionjisdescribed in 



§7.3.3 



RNA 



SCCP 



SCTP 
IP 



Data Link 
PHY 



Layer 2 



PHY 



RNC 



RNSAP 



♦■ SCCP 



> Layer 2 



*■ PHY 



Figure 7.3.1-3: lurh-lur Interfaces Protocol Stack for connectivity between a HNB and a macro RNC 

via the HNB-GW. 

7.3.2 Usage of the services provided by RNSAP User Adaptation Layer 
(RNA) 

7.3.2.1 General 

This section describes usage of RNA for lurh connectivity between HNBs. 

RNA supports the transport of any RNSAP signalling messages between HNBs. 

RNA provides a connection-oriented data transfer service and a connectionless data transfer service. 
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A signalling connection established by means of RNA is denoted by a single Context Id, which is unique within both 
involved nodes (see TS 25.471 [19] for further details). 

RNA supports direct lurh-connectivity and lurh-connectivity via the HNB-GW. 

7.3.2.2 lurh Signalling Connection Establishment 

7.3.2.2.1 Direct lurh connectivity 



Sending HNB 



Receiving IHNB 



RNA: CONNECT (lurh Context Id, RNSAP PDU, 
Senders HNB RNL Id, Receivers HNB RNL Id) 



Figure 7.3.2.2.1-1 : Signalling Connection Establishment - Direct lurh-connectivity. 

If the Sending HNB wants to send an RNSAP message to the Receiving HNB for which a dedicated lurh signalling 
connection has to be established, it issues an RNA:CONNECT message containing the lurh Context Id, the RNSAP 
PDU, the Senders HNB RNL Identity and the Receivers HNB RNL Identity. The Reception of the RNA:CONNECT 
message at the Receiving HNB completes the signalling connection establishment. 



7.3.2.2.2 



lurh signalling connection establishment via the HNB-GW 



Sending HNB 



HNB-GW 



Receiving HNB 



1. RNA:CONNECT (lurh Context Id, RNSAP PDU 
Senders HNB RNL Id, Receivers HNB RNL id) 



2. HNB-GW routes the RNA:CONNECT 
towards the HNB indicated in the Receivers 
HNB RNL Id 



3. RNA: CONNECT (lurh Context Id, RNSAP PDU, 
Sender's HNB RNL Id, Receivers HNB RNL Id) 



4. dedictated lurh signalling connection established 



Figure 7.3.2.2.2-1 : Signalling Connection Establishment - lurh connection via HNB-GW. 

1. If the Sending HNB is configured for lurh-connectivity via the HNB-GW, and wants to send an RNSAP 
message to the Receiving HNB for which a signalling connection has to be established, it issues an 
RNA:CONNECT message containing the lurh Context Id, the RNSAP PDU, the Senders HNB RNL Identity 
and the Receivers HNB RNL Identity. 

2. The HNB-GW identifies the signalling interface to which the RNA message shall be routed by Receivers HNB 
RNL Identity as received from the Sending HNB. 

3. The HNB-GW issues an RNA:CONNECT message with identical content as received from the Sending HNB to 
the Receiving HNB. 

4. Reception of the RN A:CONNECT message by the Receiving HNB completes the signalling connection 
establishment for the Receiving HNB. 



£75/ 



3GPP TS 25.467 version 11.2.0 Release 11 



56 



ETSI TS 125 467 V1 1.2.0 (2013-04) 



7.3.2.3 Transport of RNSAP signalling messages via an established lurh signalling 

connection 



7.3.2.3.1 



Direct lurh connectivity 



Sending HNB 



Receiving IHNB 



RNA: DIRECT TRANSFER (lurh Context Id, RNSAP PDU 
Receivers HNB RNL Id) 



Figure 7.3.2.3.1-1 : Transport of RNSAP messages via an established lurh signalling connection - 

Direct lurh connectivity. 

If Sending HNB, directly lurh connected to the Receiving HNB, wants to send an RNSAP message to Receiving HNB 
for which a connection oriented data transfer service is already established, it issues an RNA:DIRECT TRANSFER 
message to the Receiving HNB which contains the lurh Context Id, the RNSAP PDU and the Receivers HNB RNL 
Identity. 



7.3.2.3.2 



lurh connectivity via the HNB-GW 



Sending HNB 



HNB-GW 



Receiving HNB 



1. RNA:DIRECT TRANSFER (lurh Context Id, 
RNSAP PDU, Receivers HNB RNL Id) 



2. GW routes DIRECT TRANSFER 
based on Receivers HNB RNL Id 



3. RNA: DIRECT TRANSFER (lurh Context Id, RNSAP 
PDU, Receivers HNB RNL Id) 



Figure 7.3.2.3.2-1 : Transport of RNSAP messages via an established lurh signalling connection - lurh 

connectivity via the HNB-GW. 

If the Sending HNB, lurh connected to the Receiving HNB via the HNB-GW, wants to send an RNSAP messages via 
the established signalling connection, it issues an RNA:DIRECT TRANSFER message to the HNB-GW, providing the 
Receivers HNB RNL Identity which enables the HNB-GW to route the RNSAP message to the Receiving HNB. 

7.3.2.4 Release of a Signalling Connection 

7.3.2.4.1 Direct lurh connectivity 



Sending HNB 



Receiving HNB 



RNA: DISCONNECT (lurh Context Id, RNSAP PDU, 
Receivers HNB RNL Id) 



Figure 7.3.2.4.1-1 : Release of an lurh signalling connection - Direct lurh-connectivity. 

If the Sending HNB, directly lurh-connected to the Receiving HNB, wants to release an established signalling 
connection towards the Receiving HNB, it sends an RNA:DISCONNECT message, which includes the lurh Context Id 
and the Receivers HNB RNL Identity and may include an RNSAP PDU. Reception of the DISCONNECT message by 
the Receiving HNB completes the release of the lurh signalling connection. 
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7.3.2.4.2 



lurh connectivity via the HNB-GW 



Sending HNB 



HNB-GW 



Receiving IHNB 



RNA:DISCONNECT (lurh Context Id, RNSAP PDU, 
Receivers HNB RNL Id) 



GW routes the DISCONNECT message based 
on the Receivers HNB RNL Id 



RNA: DISCONNECT (lurh Context Id, RNSAP PDU, 
Receivers HNB RNL Id) 



Figure 7.3.2.4.2-1 : Release of an lurh signalling connection - lurh connectivity via the HNB-GW. 

If the Sending HNB, lurh connected to the Receiving HNB via the HNB-GW, wants to release the signalling connection 
towards Receiving HNB, it sends an RNA:DISCONNECT message, which includes the lurh Context Id and the 
Receivers HNB RNL Identity and may include an RNSAP PDU. The HNB-GW routes the DISCONNECT message 
based on the Receivers HNB RNL Identity. Reception of the DISCONNECT message by Receiving HNB completes the 
release of the signalling connection. 

7.3.2.5 Transport of RNSAP signalling messages via the connectionless data 

transfer service 



7.3.2.5.1 



Direct lurh connectivity 



Sending HNB 



Receiving HNB 



RNA: CONNECTLESS TRANSFER (RNSAP PDU, 
Senders HNB RNL Id, Receivers HNB RNL Id) 



Figure 7.3.2.5.1-1 : Connectionless data transfer - Direct lurh-connectivity. 

If the Sending HNB wants to send an RNSAP PDU to the Receiving HNB, for which no lurh signalling connection is 
necessary, it issues an RNA:CONNECTIONLESS TRANSFER message containing the RNSAP PDU, the Senders 
HNB RNL Identity and the Receivers HNB RNL Identity. 



7.3.2.5.2 



lurh connectivity via the HNB-GW 



Sending HNB 



HNB-GW 



Receiving HNB 



RNA:CONNECTIONLESS TRANSFER (RNSAP PDU, 
Senders HNB RNL Id, Receivers HNB RNL Id) 



GW routes the CONNECTIONLESS TRANSFER 
message based on the Receivers HNB RNL Id 



RNA: CONNECTIONLESS TRANSFER (RNSAP PDU, 
Senders HNB RNL Id, Receivers HNB RNL Id) 



Figure 7.3.2.5.2-1 : Connectionless data transfer - lurh connectivity via the HNB-GW. 

If the Sending HNB wants to send an RNSAP PDU to the Receiving HNB, for which an lurh signalling connection is 
not necessary, it issues an RNA:CONNECTIONLESS TRANSFER message containing the RNSAP PDU, the Senders 
and the Receivers HNB RNL Identities to the HNB-GW, which routes the RNA message based on the Receivers HNB 
RNL Identity. The Receiving HNB is able to identify the sending HNB by the Senders HNB RNL Identity. 
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7.3.3 Interworking between the RNSAP User Adaptation Layer (RNA) and 
the Signalling Connection Control Part (SCCP) 

7.3.3.1 General 

This section describes usage of RNA and SCCP for connectivity between a HNB and a macro RNC via HNB-GW. 

RNL signalling between an RNC and a HNB-GW utilises services provided by the SCCP (ITU-T Rec. Q.711 [32] / 
ITU-T Rec. Q.712 [33]/ ITU-T Rec. Q.713 [34]/ ITU-T Rec. Q.714 [35]) as defined for lur interface signalling 
transport between two RNCs (see 3GPP TS 25.420 [31]), since the HNB-GW is seen as an RNC from RNCs being 
connected via the lur interface to it. 

The Interworking functions at the HNB-GW deal with: 

extracting or inserting respective RNL related addressing information on the lurh connection or on the lur 
connection of the RNC-HNB signalling connectivity, 

on lurh, RNL related addressing information carried on RNA within the Receivers HNB RNL Identity IE and 
the Senders HNB RNL Identity IE, 

on lur, RNL related addressing information is carried within RNSAP; 

for connection oriented signalling, performing appropriate mapping between RNA level and SCCP level; 

respective routing of RNSAP messages based on available address information. 

In general, (i) lur connectivity between the HNB-GW and the RNC is established by configuration, while (ii) the lurh 
connectivity between the HNB and the HNB-GW is performed via the lurh setup procedure. 

The following subclauses describe the interworking between RNA and SCCP at the HNB-GW. 
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7.3.3.2 Establishment of signalling connection over lurh and lur connections between 

HNB and RNC via HNB-GW 



7.3.3.2.1 



HNB initiated 



Source HNB 



HNB-GW 



Target RNC 



1. RNAiCONNECT (lurh Context Id, RNSAP PDU,, 
Senders HNB RNL Id = HNB's Global Cell Id, 
Receivers HNB RNL Id = Global RNC Id of Target RNC), 



2. The HNB-GW: 

(a) routes RNSAP PDU, to Target RNC (lur already configured). 

(b) maintains a mapping between the SCCP-based signalling 
connection and the RNA-based signalling connection 



3. SCCP connection establishment as described in TS 25.420 [31] 
subclause 4.5.1 .3. The RNC processes the received RNSAP PDU, and 
replies at application level with RNSAP PDU2. 



4. HNB-GW routes RNSAP PDU2 to the appropriate HNB based on 
the mapping between the SCCP-based signalling connection and 
the RNA-based signalling connection. 



5. RNAiDirect Transfer (lurh Context Id, RNSAP PDU2 
Senders HNB RNL Id = Global RNC Id of Target RNC, 
Receivers HNB RNL Id = Source HNB's Global Cell Id) 



HNB and RNC lurh/lur connected 



'or the specific signalling connection 



Figure 7.3.3.2.1-1 : Establishment of signalling connection over lurh and lur connections between 

HNB and RNC via HNB-GW - HNB Initiated. 

1. If the Source HNB is configured for lurh-connectivity via the HNB-GW, and wants to send an RNSAP message 
to the Target RNC for which signalling connection over lurh and lur connections has to be established, it issues 
an RNA:CONNECT message containing the lurh Context Id, the RNSAP PDUi, the Source HNB RNL Identity 
and the Target RNC RNL Identity. 

2. The HNB-GW identifies the signalling interface to which the RNA message shall be routed by the Target RNC's 
RNL Identity as received from the Source HNB and maintains a mapping between the RNA-based signalling 
connection and the SCCP-based signalling connection for the HNB-RNC end-to-end. 

3. The HNB-GW sends RNSAP PDU, to the Target RNC and the Target RNC sends back RNSAP PDUz (see TS 
25.420 [31] subclause 4.5. 1.3). 

4. The HNB-GW routes the RNSAP PDU, towards the Source HNB. 

5. The HNB-GW sends an RNA:Direct Transfer message, including RNSAP PDUz received from the Target RNC. 
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7.3.3.2.2 



HNB initiated - Refusal from RNC 



Source HNB 



HNB-GW 



Target RNC 



1. RNA:CONNECT (lurh Context Id, RNSAP PDUi, 
Senders HNB RNL Id = HNB's Global Cell Id, 
Receivers HNB RNL Id = Global RNC Id of Target RNC). 



2. The HNB-GW: 

(a) routes RNSAP PDU, to Target RNC (lur already configured). 

(b) maintains a mapping between the SCCP-based signalling 
connection and the RNA-based signalling connection 



3. SCCP connection establishment as described in TS 25.420 [31] subclause 
4.5.1.3. The RNC refuses the connection due to, e.g., limited resources. A 
RNSAP PDU2 may be included in the in the SCCPiCREF message 



4. HNB-GW maps the SCCP:CREF into a RNAiDISCONNECT 
based on the mapping between the SCCP-based signalling 
connection and the RNA-based signalling connection 



5. RNA:DISCONNECT (lurh Context Id, Receivers HNE 
RNL ld=Source HNB's Global Cell Id, RNSAP PDU2) 



Figure 7.3.3.2.2-1 : Establishment of signalling connection over lurh and lur connections between 
HNB and RNC via HNB-GW - HNB Initiated with refusal from RNC. 

1. If the Source HNB is configured for lurh-connectivity via the HNB-GW, and wants to send an RNSAP message 
to the Target RNC, it issues an RNA:CONNECT message containing the lurh Context Id, the RNSAP PDU|, the 
Source HNB RNL Identity and the Target RNC RNL Identity. 

2. The HNB-GW identifies the signalling interface to which the RNA message shall be routed by the Target RNC's 
RNL Identity as received from the Source HNB and maintains a mapping between the RNA-based signalling 
connection and the SCCP-based signalling connection for the HNB-RNC end-to-end communication. 

3. The HNB-GW sends RNSAP PDU, to the Target RNC as received from the HNB via SCCP:Connection 
Request and the Target RNC refuses the connection request (see TS 25.420 [31] subclause 4.5.1.3). 

4. The HNB-GW maps the SCCP:CREF message into an RNA:DISCONNECT. 

5. The HNB-GW sends an RNA:DISCONNECT message, including the optional RNSAP PDUj if received from 
the Target RNC. 
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7.3.3.2.3 



RNC initiated 



Target HNB 



HNB-GW 



Source RNC 

I 



Note: RNC routes the 
RNSAP PDU to the HNB- 
GW based on the RNC-id 
portion of the target cell 



. SCCP:CR (Data=RNSAP PDUi) 



2. The HNB-GW routes RNSAP PDU to a HNB based on the 
contained cell Identification 



3. RNA:CONNECT (lurh Context Id, RNSAP PDU, 
Senders HNB RNL Id = Global-RNC Id of Source RNC, 
Receivers HNB RNL Id = Target HNB's Global Cell Id) 



4. HNB processes RNSAP PDU, and answers on 
application level (RNSAP PDU2) and signalling TNL level 
(RNA Direct Transfer) 



5. RNA:Direct Transfer (lurh Context Id, RNSAP PDU- 
Senders HNB RNL ld=Target HNB's Global Cell Id, 
Receivers HNB RNL Id Id = Global RNC-ld of Source 



RhC 



6. HNB-GW routes RNSAP PDU2 to the proper RNC 



HNB and RNC lurh/lur connected 



7. SCCP:CC (Data=RNSAP PDU2I 



'or the specific signalling connection 



Figure 7.3.3.2.3-1 : Establishment of signalling connection over lurh and lur connections between 

HNB and RNC via HNB-GW - RNC Initiated. 

1. The HNB-GW is seen by Source RNC as a (configured) neighbour RNC. Any signalling towards a target cell 
with a respective RNC-Id-prefix is sent to the HNB-GW. In this case the RNC triggers the SCCP connection 
establishment as described in TS 25.420 [31] subclause 4.5.1.3. 

2. The HNB-GW has to be able (i) to extract the Target HNB RNL Id from the (Global) Cell-Id indicated in the 
initiating RNSAP PDU and (ii) to maintain a mapping between the SCCP-based signalling connection and the 
RNA-based signalling connection for the HNB-RNC end-to-end communication. 

3. The HNB-GW sends an RNA:CONNECT message towards the appropriate HNB including the lurh Context Id 
generated at Step 2, RNSAP PDUi received from the RNC and the Global Ids of RNC and HNB. 

4-7. At the reception of the RNA:CONNECT message, the Target HNB processes RNSAP PDUi, generates the 
response RNSAP PDU2. The HNB replies then with an RNA:Direct Transfer message including the new 
RNSAP PDU2 and the RNC and HNB Ids. The HNB-GW will forward such pieces of information to the RNC 

(TS 25.420 [31] subclause 4.5.1.3). 
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7.3.3.3 Transport of RNSAP signalling messages via signalling connection 

established over lurh and lur connections 



7.3.3.3.1 



HNB initiated 



Sending HNB 



HNB-GW 



Receiving RNC 



1. RNA:DIRECT TRANSFER (lurh Context Id, 
RNSAP PDU, Receivers HNB RNL Id) 



2. HNB-GW routes RNSAP PDU to the 
proper RNC 



3. SCCP encapsulated RNSAP PDU 



Figure 7.3.3.3.1-1 : Transport of RNSAP messages via signalling connection over lurh and lur 

connections - HNB initiated. 

If the Sending HNB wants to send an RNSAP message to the Receiving RNC for which a connection oriented data 
transfer service is already established, it issues an RNA:DIRECT TRANSFER message towards the HNB-GW which 
contains the lurh Context Id, the RNSAP PDU and the Receivers HNB RNL Identity. 

The HNB-GW will forward the RNSAP PDU to the Receiving RNC within an SCCP message. 



7.3.3.3.2 



RNC initiated 



Receiving HNB 



HNB-GW 



Sending RNC 



1. SCCP encapsulated RNSAP PDU 



2. HNB-GW routes RNSAP PDU to the 
appropriate HNB 



3. RNA:DIRECT TRANSFER (lurh Context Id, 
RNSAP PDU, Receivers HNB RNL Id) 



Figure 7.3.3.3.1-1 : Transport of RNSAP messages via signalling connection over lurh and lur 

connections - RNC initiated. 

If the Sending RNC wants to send an RNSAP message to the Receiving RNC for which a connection oriented data 
transfer service is already established, it will send to the HNB-GW the RNSAP PDU within an SCCP message. 

The HNB-GW will then generate an RNA:DIRECT TRANSFER message and will route the RNSAP PDU to the 
correct HNB. 
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7.3.3.4 Release of signalling connection over lurh and lur Connections 

7.3.3.4.1 HNB initiated 



HNB 



HNB-GW 



RNC 



1. RNA:DISCONNECT (lurh Context Id, RNSAP 
FPU, Receivers HNB RNL Id = Global RNC-ld) 



2. HNB-GW maps the DISCONNECT message to an 
SCCPiRLSD and passes an RNSAP PDU if contained 
intheRNA:DISCONNECT 



3. SCCP connection release, as described in TS 25.420 [31] 



Figure 7.3.3.4.1-1 : Release of established signalling connection over lurh and lur connections - HNB 

initiated. 

If an HNB wants to release a signalling connection previously established over lurh and lur connections previously 
established towards an RNC, it sends an RNA:DISCONNECT message, which includes the lurh Context Id and the 
Receivers HNB RNL Identity (i.e., the Global RNC Id) and may include an RNSAP PDU. The HNB-GW maps the 
RNA:DISCONNECT message to an SCCP:Released message and triggers the SCCP connection release procedure 
defined in TS 25.420 [31] subclause 4.5.1.4. 



7.3.3.4.2 



RNC initiated 



HNB 



HNB-GW 



RNC 



1. SCCP connection release, as described in TS 25.420 [31] 



2. HNB-GW maps the SCCPiRLSD message to an 
RNAiDISCONNECT Including the RNSAP PDU if 
received from the RNC 



3. RNAiDISCONNECT (lurh Context Id, RNSAP 
PDU, Receivers HNB RNL ld=HNB"s Global Cell Id) 



Figure 7.3.3.4.2-1 : Release of established signalling connection over lurh and lur connections - RNC 

initiated. 

If an RNC wants to release a signalling connection previously established over lurh and lur signalling connections 
previously established towards an HNB, it behaves as described in TS 25.420 [31] subclause 4.5.1.4. 

The HNB-GW maps the SCCP:RLSD to an RNAiDISCONNECT message and forwards it to the HNB. This last 
message includes the proper lurh Context Id. the Receivers HNB RNL Identity (i.e., the HNB Global Id) and an 
RNSAP PDU, if previously received from the RNC. 
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7.3.3.5 Transport of RNSAP signalling messages via the connectionless data 

transfer service 



7.3.3.5.1 



HNB initiated 



Sending HNB HNB-GW 


Receiving RNC 




1. RNA:CONNECTIONLESS TRANSFER (RNSAP PDl 
Senders HNB RNL Id = HNB's Global Cell Id, 
Receivers HNB RNL Id = Global RNC-ld) 


1, 


















2. HNB-GW routes the CONNECTIONLESS TRANSFER message based on the 
RNC-ld. SCCP may, according to TS 25.420 [31] use SSN/SPC/GT addressing. 










3. SCCP encapsulated RNSAP PDU 








^ 




^^H 


^^M ^^1 


^^M ^^H 


^^H 



Figure 7.3.3.5.1-1 : Connectionless data transfer over lurh and lur connections - HNB initiated. 

If the Sending HNB wants to send in a connectionless manner an RNSAP PDU to the HNB-GW for the Receiving 
RNC, it issues an RNA:CONNECTIONLESS TRANSFER message containing the RNSAP PDU, the Senders and the 
Receivers HNB RNL Identities. 

The HNB-GW then generates and routes the RNSAP PDU within an SCCP message towards the Receiving RNC. 



7.3.3.5.2 



RNC initiated 



Receiving IHNB 



HNB-GW 



Sending RNC 



1. SCCP encapsulated RNSAP PDU 



2.HNB- GW routes the CONNECTIONLESS TRANSFER message based on an 
identification within the RNSAP PDU 



3. RNA:CONNECTIONLESS TRANSFER (RNSAP PDU, 
Senders HNB RNL Id = Global RNC-ld, 
. Receivers HNB RNL Id = HNB Global Cell Id) 



Figure 7.3.3.5.2-1 : Connectionless data transfer over lurh and lur connections - RNC initiated. 

If the Sending RNC sends an RNSAP PDU to the HNB-GW for the Receiving HNB, the HNB-GW has to be able to 
extract the receiving HNB"s RNL address from received RNSAP PDU. Then the HNB-GW issues an 
RNA:CONNECTIONLESS TRANSFER message containing the RNSAP PDU, the Senders and the Receivers HNB 
RNL Identities to the receiving HNB. The Receiving HNB is able to identify the sending RNC by the Senders HNB 
RNL Identity. 
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8 Enhanced Interference Management 



8.1 



General 



There is a type of interference which may be considered: 1) Interference from HNB to Macro. 
Scenarios are Hsted in Table 8.1-1. 

Table 8.1-1. Interference scenarios. 



Scenario 


Aggressor 


Victim 


Type of interference 


1 


HNB UE (UL) 


Macro NB 


Interference from HNB to Macro 

*applicable to co-channel deployment scenario 


2 


HNB (DL) 


Macro UE 



8.2 Mitigation of interference from HNB to IVIacro 

8.2.1 Interference from HNB UE (UL) to IVIacro NB 

The scenario involves :- 

1. Adaptively limiting the HNB UE"s maximum UL Tx Power in connected mode possibly using HNB UE 
measurement and calculating the path loss between HNB UE and Macro NB. 

8.2.2 Interference from HNB (DL) to Macro UE 

The scenario involves :- 

1. Redirecting unauthorized UE to another carrier possibly based on uplink access attempts by unauthorised UE. 

2. Adjusting HNB"s DL CPICH Tx Power adaptively either temporarily or over long term possibly based on uplink 
access attempts by unauthorised UE. 
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Annex A (informative): 

Implementation of CN functions within the HNB-GW for 

support of inter-HNB intra-HNB-GW SRNS Relocation 

A.1 Scope 

The implementation option described in this Annex will not be evolved or maintained/corrected by 3GPP in the current 
Release or future Releases of the 3GPP specifications. The mechanism in subclause 5.7 is the mechanism that shall be 
maintained, and for which evolution within 3GPP is applicable. 

A.2 General 

This Section describes an implementation variant where CN functions of SRNS Relocation are implemented within the 
HNB-GW in order to hide intra-HNB-GW inter-HNB active mode mobility from the CN. 

From a HNB perspective the HNB-GW appears as a CN node (one node per CN domain) providing all necessary 
protocol functions for SRNS Relocation (Hard Handover), from a CN node perspective, the HNB-GW appears as an 
RNC serving the inter-HNB relocations as intra-RNC mobility. 

The following sub-sections describe the respective mechanisms. The RANAP messages are exchanged over the luh 
interface from the Source-HNB to the HNB-GW and from the HNB-GW to the Target-HNB using appropriate RUA 
encapsulation. 

In this implementation the lu UP protocol is still terminated in the CN and HNB (Figure 7.2-1), but there is an lu UP 
Interworking function (A. 10) residing in the HNB-GW. This implementation variant supports SRNS Relocation 
between HNBs supporting the same RFC combinations if the HNB supports only lu UP vl and SRNS Relocation 
between all HNBs supporting lu UP v2. 

A.3 Mobility procedure 
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UE 



Source 
HNB 



HNBGW 



1. Ongoing OS PS session 



2 Decision to reiocate UE to 
target HNB 



CN 



7 . Physicai Channei 
Reconfiguration 



3 . RUA DIRECT TRANSFER { UE Context ID 
CN Domain RANAP Relocation Required) 



4 . Prepare RANAP message 



Target 
HNB 



5 . HNB GW triggered UE Registration 



6. RUA DIRECT TRANSFER(UE Cbnte4 ID 
CN Domaig RANAP Reiocation Command ) 



8 . UL Synchronization 



9 . RUA DIRECT TRANSFER { UE Context IC 
CN Domaig RANAP Reiocation Detect) 



10 



Physicai Channei Reconfiguration Compiete 



1 1 . RUA DIRECT TRANSFER ( UE Contesxt 
CN Domain RANAP Reiocation Compiete 



D 



12. RUA DIRECT TRANSFER( UE Context ID 
CN Domain RANAP iu Release Command ) 



13. RUADISCONNECT(UEContext,IDCN 
Domain, RANAP iu Release Compiete ) 



4 . HNBAP UE DEREGISTER (UE Context ID ) 



Figure A.3-1 : Inter-HNB Inter-HNB-GW SRNS Relocation - Implementation of CN functions for SRNS 

Relocation within the HNB-GW. 

1. The UE has established an active CS/PS session to the CN via the source HNB and HNB-GW. 

2. At some point, the source HNB makes a decision to relocate the UE session. 

3. The source HNB triggers relocation of the UE session by sending the RANAP Relocation Required message 
encapsulated in the RUA Direct Transfer message to the HNB-GW. The target RNC-Id and target Cell-Identity 
information along with relocation information are included by the source HNB in the RANAP Relocation 
Required message. 

4. The HNB-GW constructs the RANAP RELOCATION REQUEST using the stored RAB Parameters and 
parameters received from source HNB. The RANAP message also includes the HNB-GW UL TNL information 
for each RAB to be setup at the target HNB. 

5. Steps for HNB-GW Triggered UE Registration are executed between the HNB-GW and the HNB. The luhUPIF 
function handles the CS user plane establishment in the HNB-GW. The RANAP message from the target HNB 
includes the target HNB DL TNL information for each RAB to be setup. In case the target HNB decides to use 
the alternative RAB parameters and indicates the same in the RANAP RELOCATION ACKNOWLEDGE 
message, the HNB-GW rejects the relocation towards the target HNB and redirects original relocation request 
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towards the CN node as in subclause 5.9. 

In this phase, HNB-GW may begin bi-casting DL traffic to the source and target HNB. 

6. The HNB-GW constructs the appropriate RANAP Relocation Command message and routes the RANAP 
message encapsulated in the RUA Direct Transfer message to the source HNB. 

7-11. The rest of the relocation procedure continues as shown in the corresponding steps in the above figure. When 
the relocation is detected in HNB-GW, the HNB-GW switches the user plane from the source HNB to the target 
HNB. 

12. The HNB-GW upon getting an indication that the UE has been successfully relocated to the target HNB triggers 
the lu release procedure towards the source HNB by sending a RUA encapsulated RANAP lu Release Command 
message. 

13. The source HNB acknowledges the lu release procedure to the HNB-GW by sending a RUA encapsulated 
RANAP lu Release Complete message. 

NOTE: Steps 2 to 13, as appropriate, are repeated for the second CN domain when present with the following 
exception. There is only one Context Id allocated to the UE regardless of the number of signalling 
domains relocated. 

14. The HNB-GW deregisters the UE from the source HNB. The source HNB releases the resources assigned to the 
UE and deletes all stored context information associated with the UE. 



A.4 luh Control Plane Aspects 



The HNB-GW processes and forwards some of the connection-oriented RANAP messages, related to RAB 
Management, Data Volume Reporting, UE Tracing, Location Reporting, Security and lu UP Initialisation. 



A. 5 luh user plane aspects 



The HNB-GW processes and forwards all the user plane packets between the HNB and the CN and performs the 
switching of the user plane between the source and the target HNB. 



A. 6 RAB management Functions 



The establishment, modification or release of a RAB is performed between the HNB and the CN as specified in TS 
25.413 [9]. However, the HNB-GW stores the RAB parameters of each established RAB as signalled via respective on 
the RANAP messages during RAB establishment, modification and SRNS Relocation. 



A. 7 Data Volume Reporting 



The data volume reporting function is used to report the volume of unsuccessfully transmitted DL data of PS RABs to 
the CN. If the CN has initiated the data volume report then in order to continue data volume reporting after the 
finalisation of the SRNS Relocation, the HNB-GW includes the Data Volume Reporting Indication in the RANAP 
RELOCATION REQUEST message towards the target HNB. The HNB-GW accumulates data volume reports from the 
different HNBs involved in subsequent inter-HNB intra-HNB-GW SRNS Relocations and reports the final value to the 
SGSN at RAB release. 



A.8 UE Tracing 



This feature allows tracing of various events related to the UE and its activities. The HNB-GW stores the Trace related 
RANAP parameters exchanged in the RANAP signalling messages. In order to continue UE tracing in the target HNB 
during and after SRNS Relocation, the HNB-GW sends the stored RANAP CN INVOKE TRACE encapsulated in the 
RUA DIRECT TRNSFER message towards the target HNB after step 5 (see subclause 5. 1 1.2). 
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A. 9 Location reporting function 



The positioning function performs the determination of the geographical position for an UE. The location reporting 
function transfers the positioning information between the UTRAN and the CN triggered by the RANAP Location 
Reporting Control from the CN. If the RANAP Location Reporting Control procedure is initiated with 'Request Type ' 
indicated as 'to report upon change of Service area', the HNB-GW sends the Location Report if there is a change in SA 
due to SRNS Relocation. Also, the HNB GW sends the stored RANAP LOCATION REPORTING CONTROL 
encapsulated in the RUA DIRECT TRANSFER message towards the target HNB after step 5 (see subclause 5. 11. 2) if 
Location Reporting Control procedure continues after relocation. 

A. 10 Security Functions 

The radio interface is ciphered/integrity protected upon request of the Core Network. The ciphering/ integrity protection 
is done within UTRAN at the HNB. However, the HNB-GW stores the ciphering and integrity protection related 
RANAP parameters exchanged in the UE dedicated RANAP signalling messages. The HNB-GW includes the stored 
ciphering/integrity protection information in the Relocation Request message to the target HNB. 

A.1 1 luh Framing Protocol Interworking Function (luhUPIF) 
A. 11.1 Introduction 

The CS user plane traffic on the luh interface (between HNB and HNB-GW) carried using the lu UP framing protocol 
as defined in the TS 25.415 [17] UTRAN lu interface user plane protocols. The HNB lu UP entity follows the 
procedures and principles defined in the lu UP framing protocol specification (TS25.415 [17] UTRAN lu interface user 
plane protocols). Most of the lu UP PDUs will be transferred by the HNB-GW without any processing. However, the 
HNB-GW will perform certain functionalities that could be implemented by an luhUPIF (luh user plane interworking 
function) in the HNB-GW as described below. 

The luhUPIF is the functional entity responsible for aligning or mapping control procedures (including RFCIs, frame 
numbers etc) on the separate UP interfaces. The luhUPIF determines if the two UP configurations (at the HNB and CN) 
are identical and thus the UP PDUs may be passed transparently. If the luhUPIF determines that the two UP 
configurations are not identical it applies the necessary mapping. 



luh Interface 



lu/lnterface 



c 



r ^^ luhUPIF ' 



RNL/CNL-SAP 



RNL/CNL-SAP 



Support Mode 



> Support 
Functioi 



Transfer of lu 

FP protocol 

frames 



^^^1 TNL-SAI 



Support Mode 
Functions 



Transfer oflu 

FP protocol 

frames 



^C 



HNBGW 



Figure A.11.1-1. The luh Framing Protocol Interworking Function. 
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A.11 .2 CS User Plane handling during the Initial CS RAB setup 

During the CS RAB setup, the HNB allocates the RAB Subflows combination indicator for the SDU formats (SDU 
formats are sent to the HNB in the RANAP RAB ASSIGNMENT message). The allocation is then sent in the lu 
Framing Initiahsation PDU by the HNB in the user plane. For further details see TS 25.413 [9] and TS 25.415 [17]. 

Upon reception of the RFCI values in the lu UP Initialisaiton Frame (lu UP PDU type 14 from the HNB ) during the 
call establishment, the HNB-GW stores 'UL RFCI vector'. The first subflow of the initialisation corresponds to the 
Initial Rate control i.e. indicate the highest rate for the first speech mode to be used in the direction of the Initialisation 
acknowledgement frame. The HNB-GW forwards the lu UP Initialisation frame towards the CN according to TS 
25.415 [17] without any change to the received lu UP PDU from the HNB. Upon reception of the lu UP ACK/NACK 
PDU, the HNB-GW forwards it towards the HNB. 



HNB 



HNBGW 



MSC/MGW 



STORE RFCIs, 
Acknowledge lu framing 
proteol Init, terminate tlie 
lu framing protocol. 



lu UP INIT 



STORE RFCIs, forward 
control PDUs to network 
sideofMGW 



lu UP INIT ACK/NACK 



/ 



lu UP INIT 



lu UP INIT ACK/NACK 



Figure A.11. 2-1. lU UP Handling during the Initial call setup. 



A. 11 .3 CS User Plane handling after the finalisation of SRNS Relocation 

During the SRNS Relocation, as part of the RANAP Relocation Resource Allocation procedure, the target HNB 
performs the user plane initialisation. The (Target) HNB allocates the RAB Subflows combination indicator(s) for the 
each SDU formats (SDU formats are sent to the HNB in the RANAP RELOCATION REQUEST message). The 
allocation is then sent in the lu Framing Initialisation PDU by the HNB in the user plane. For further details see TS 
25.413 [9] and TS 25.415 [17]. 
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HNB 



STORE RFCIs, 
Acknowledge lu framing 
protcol Init, terminate the 
lu framing protocol. 



lu UP INIT 



HNBGW 



MSC/MGW 



STORE RFCIs, 
Aclinowledge lu 
framing protcol Init. 



lu UPINITACK 



lu UP RATE CONTROL 



Map RFCI if 
necessary 



lu UP Packets 



Figure A.11.3-1. lU UP Handling after SRNS Relocation. 

At reception of an lU UP Initialisation Frame (lu UP PDU type 14) from the Target HNB, the HNB-GW stores received 
RFCI indexes (per data rate) in the form of ordered sequence (received in the initialisation PDU) as 'UL RFCI Vector' 
and send the Initialisation acknowledgment to the target HNB. The HNB-GW does not perform the forwarding of the 
luUP initialisation on the lu interface. The HNB-GW checks whether the received RFCI allocations match the stored 
RFCI allocation for the same bearer established with the source HNB. The HNB-GW performs the following functions: 

RFCI Mapping function: If the allocated RFCI index (s) does not match with the existing RFCI index(s) for the 
corresponding data rates, then the HNB-GW performs the RFCI Mapping function. That is, for every subsequent 
lu UP frame upon the relocation, the HNB-GW maps the RFCI indices of the incoming side (from the HNB) to 
the corresponding RFCI indicates to the outgoing side (towards the MSC that is already stored in the HNB-GW) 

and vice versa. 

In case lu UP version 1, if the maximum rate indicated by the target HNB in the lu UP INIT is different from the 
current used maximum rate then the HNB-GW initiates a Rate Control PDU indicating the new maximum rate to 
the MSC. 

A. 11. 4 FQC 

The HNB-GW (luhUP IF) does not handle the FQC included in the UP frames. The value included in the lu UP frame 
is passed to the peer not without any modification. 

A.1 1.5 Frame number 

The frame number indicated by the peer node (i.e. lu or luh) on the receiving side is forwarded unmodified to lower 
layer on the sending side. 

A.1 1.6 Time alignment Procedure: 

When a HNB-GW (luhUP IF) entity receives a time Alignment Command over the lu or luh interface, it is relayed 
unmodified to the other peer node. 

A.1 1 .7 Rate Control Procedure 

When an HNB-GW (luhUP IF) entity receives a Rate Control over the lu or luh interface, it forwards to the other peer 
node) with "RFCI Mapping" where appropriate. 



ETSI 



3GPP TS 25.467 version 11.2.0 Release 11 



72 



ETSI TS 125 467 V1 1.2.0 (2013-04) 



A. 11. 8 Payload 

When a HNB-GW (luhUP IF) entity receives the payload SDUs, the received SDUs is forwarded unmodified to the 
either side (HNB or HNB-GW) with "RFCI Mapping" where appropriate. 

A.1 1.9 lu UP Re-Initialisation 

When an HNB-GW (luhUP IF) entity receives a lu UP Initialisation from the CN, it stores the 'DL RFCI Vector' and 
then forward it to the HNB without any modification in the RFCIs. Upon reception of the lu UP ACK/NACK PDU, the 
HNB-GW forwards it towards the CN. 



HNB 



STORE RFCIs, 
Acknowledge lu framing 
proteol Init, terminate tlie 
lu framing protocol. 



lu UP INIT 



HNBGW 



MSC/MGW 



STORE RFCIs and 
forward control PDUs to 
the HNB 



lu UP INIT ACK/NACK 



lu UP INIT 



lu UP INIT ACK/NACK 



Figure A.11.9-1. lU UP Re- Initialisation. 
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Annex B (informative): 
Deployment Architecture 



B.1 Direct lurh connectivity between HNBs 

The reference model shown in Figure B.1-1 below illustrates an HNB access network with direct lurh connectivity. 

1 luh 



Uu 

< — — ► 



HNB 



lurh 



Security 
Gateway 



Uu 




luh 



HNBGW 



lu 



HMS 



Figure B.1-1. HNB access network deploying direct lurh connectivity. 

An alternative HNB access network configuration deploying the lurh interface transported via the Security Gateway is 
shown in Figure B.1-2. 

NOTE: If the Security Gateway and the HNB-GW are co-located then the co-located node should support IP 
routing. 




HNBGW 



lu 



HMS 



Figure B.1-2. HNB access network deploying lurh connectivity via a Security Gateway. 

An alternative arrangement with the lurhr interface transported via the Security Gateway and the HNB-GW is shown in 
Figure B.1-3. The HNB-GW provides transport routing functionality. 
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HNBGW 



lu 



HMS 



Figure B.1-3. HNB access network deploying lurh connectivity via the l-INB-GW. 
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Annex C (informative): 

Implementation of PSC Disambiguation for Support of 

Legacy UE IVIobility from RNC to HNB 



C.1 Scope 



In some HNB deployments the limited number of PSCs available to be allocated to HNBs may cause PSC ambiguity. 
This may result in the inability of identifying, at the source macro RNC, a unique target HNB corresponding to a PSC 
reported by a Legacy UE (i.e., UEs not capable of SI acquisition). 

In this informative annex two solutions for PSC disambiguation are described. 

The implementation options described in this Annex are not intended to be evolved in the 3GPP specifications. 

C.2 Disambiguation at the RNC 

This implementation option can be split in two different steps: 

Step 1 : At first, during previous HNB to RNC mobility, the RNC builds a local database of necessary information 
concerning neighbouring cells with PSC confusion (e.g., neighbouring cells PSCs, Cell IDs, Observed Time Difference 
(OTD)). This local database is built/maintained via handover preparation signalling. The HNB shall include the full 
Measurement Report and the source cell ID in the handover preparation signalling, and the target RNC collects 
incoming data and adds/updates OTD information to its database. 

Step 2: In a second phase, during RNC to HNB mobility (hand-in), the RNC uses the information previously gathered in 
order to disambiguate the target HNB in case of a certain PSC is reused in a given (target) area. 

C.2.1 Step 1 : Construction of HNB database in tine RNC 

Figure C.2. 1-1 depicts the first step of this implementation option. It consists in the RNC building the database of HNBs 
during HNB to RNC mobiUty. Such database includes PSCs, Cell IDs and Assistance data (e.g., OTD). 




Figure C.2.1 -1 : Step 1 - Example of RNC constructing database of l-INBs during l-INB to RNC mobility. 

This first step can be split in the following sub-steps: 

A. The UE under control of the HNB is configured to provide measurement reports, including OTD data. 

Such measurement report, e.g., can be carried within an RRC:Measurement Report to the HNB and, 
subsequently, to the target RNC via handover preparation procedures. 
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B. The HNB initiates relocation towards macro cells, by including the source cell identity and full Measurement 
Report in the Source RNC to Target RNC Transparent Container, 

C. The Macro RNC collects incoming data and adds/updates OTD information to its database. 

At this stage, the Macro RNC has built a database with all necessary information for future RNC to HNB relocation 
(hand-in). 

C.2.2 Step 2: PSC disambiguation executed by tine RNC during RNC to 
HNB inand-in 

Figure C.2.2-1 depicts the second step of implementation option. The RNC, during RNC to HNB mobility (hand-in), 
can disambiguate the target HNB on the basis of the information collected in the target cells database. 




CN 



HNB-GW 
&HNB 




RNC 



B 



A 






Figure C.2.2-1 : Step 2 - Example of PSC disambiguation at RNC during RNC to HNB relocation. 

As shown in the figure above, the second step of this implementation option consists of the following sub-steps: 

A. The RNC enables the normal measurement reporting to a 'shared' PSC in the area; 

B. In case of shared target PSC and if the UE is not SI reading capable, the RNC checks the cells reported in the 
measurement report, calculates the AOTD information based on the measurement report and finds the best match 
in the database created in Step 1 ; 

C. The RNC initiates relocation towards the selected target HNB as per normal mobility procedures. 

C.3 Disambiguation at the HNB-GW 

This solution allows the HNB-GW to identify the target HNB based on the source Cell ID and the measurements 
including OTD which are reported by the UE during the handover as shown in Figure C.3-1. The procedure includes 
two parts: 

- Construction and Update of HNB Timing Information (AOTD) Database at the HNB-GW. 

Target Cell Disambiguation at the HNB-GW during handover to a HNB connected to this HNB-GW. 
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^^ Disambiguation using 
AOTD + Source Cell 



RANAP Relocation Request 
(Source Cell Id, 



Core Network 



RANAP Relocation Required 
(Source Cell Id, HNB-GWid, 
OTD^Hm OTD i u i MH from Stop 1 ) 







HNB2 HNB, tT,^^ ^ 
Confusion) 






Figure C.3-1 : AOTD based disambiguation at the HNB-GW. 

C.3.1 Construction and Update of AOTD Database at the HNB-GW 

AOTD = (OTDhnb - OTD mnb) represents a HNB"s timing with respect to a macro cell (MNB) as measured by the UE 
where AOTDceii is the timing of a UE with respect to a given cell [25]. The HNB-GW keeps a database of the AOTD 
values for HNBs under its control and their neighbour MNB cells. The HNB-GW also keeps the mapping of a MNB"s 
Cell ID and its PSC. 

The HNB-GW updates the AOTD database by using the information provided by the UEs during handovers to MNB 
cells. During these hand-outs, a HNB includes the MEASUREMENT REPORT message (MRM) in the RRC 
transparent container which is sent in the RANAP Relocation Required message and set the Target Cell Id IE to the ID 
of the macro cell with respect to which the OTD is computed. 

C.3.2 Target Cell Disambiguation for Handover to the HNB 

The procedure can be implemented as follows: 

1 . UE is triggered to send an RRC Measurement Report (including OTD for both source and target cells) to the 
SRNC by the rules set by the UTRAN. 

2. The source RAN triggers relocation of the UE session by sending the RANAP RELOCATION REQUIRED 
message to the Core Network: 

The time difference information of the target HNB cell and the source Macro cell is contained in the RRC 
Container IE as defined in TS 25.331 [25]. 

Source Cell ID is transmitted in the Source RNC to Target RNC Transparent Container. 

Target Cell ID IE may be set to a special value since the actual Cell ID is not known. 

3. HNB-GW determines that PSC disambiguation is needed when target cell ID does not identify a HNB under its 
control. The HNB GW selects the target HNB using the received information (including the source Cell ID and 
MRM) and the AOTD database. 

4. The remainder of the relocation procedure continues normally as documented in 3GPP TS 25.413 [9] and 3GPP 
TS 23.060 [10]. 

Additionally, after the successful inbound handover, the HNB GW can update the AOTD information between the 
target HNB cell and the source MNB cell using the received information. 

C.4 Notes 

For both solutions described above, the following notes apply: 

NOTE 1: It is assumed that the HNB GW/RNC has the mapping of neighbouring cells PSCs and Cell IDs. 
NOTE 2: If OTD signatures are not maintained up to date, handover failures may occur. 
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NOTE 3: The range of AOTDs will be different for intra and inter-frequency cell measurements (e.g., when the 
HNB cell is measured on another frequency than the source cell). Consequently the disambiguation 
performance in the two scenarios may differ. 
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